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with the information needed to write efficient pro- 
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schedule, implement and control the transfer of data 
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tions related to the transfer of data, such as error 
detection and correction. 

Included in this publication are detailed descrip- 
tions of the dtf (Define The File) statements, the 
Basic Input/Output Control System macro-instruc- 
tions, disk file processing using the Basic Input/Output 
Control System, and certain aspects of the Internal 
Operation of the iocs that will enable the programmer 
to take advantage of the flexibility of iocs. 
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Introduction 



Purpose of this Publication 

This publication provides programmers with the in- 
formation necessary to write efficient programs using 
the Basic Input/Output Control System of the IBM 
1410/7010 Operating System. 

Purpose of the IOCS 

The Basic Input/Output Control System (hereafter 
referred to as the iocs) provides programmers with a 
tested, efficient means of scheduling, implementing, 
and controlling the transfer of data between specified 
input/output devices and 1410 or 7010 core storage. 

Specifically, the iocs can perform the following 
functions : 

1. Bead data records or blocks of data records from 
the ibm 1402 Card Bead Punch, ibm 1442 Serial Card 
Beader, ibm 1011 Paper Tape Beader, ibm 729 and 
7330 Magnetic Tape Units, and ibm 1301 Disk Storage. 

2. Write data records or blocks of data records on 
the 1402 Card Bead Punch, ibm 1403 Printer, 729 and 
7330 Magnetic Tape Units, and 1301 Disk Storage. 

3. Detect error conditions, and correct those error 
conditions that lend themselves to correction. 

4. Block and deblock data records. 

5. Overlap read/write and processing operations. 

6. Bead, check, and write tape labels. 

7. Provide exits to user-written routines such as end- 
of-file routines. 

8. Detect requests for Tele-Processing® interrupts 
and pass control to the Tele-Processing Supervisor so 
that such requests can be processed. 

9. Provide for automatic rewinding, rewinding and 
unloading, or backspacing of the various reels of tape 
files at specific points in the user's program. 

Prerequisites 

It is assumed that readers of this publication have 
completed a basic course in programming the ibm 
1410 or 7010 Data Processing Systems, and are familiar 



with the information contained in the following pub- 
lications : 

IBM 1410/7010 Operating System; Basic Concepts, 
Form C28-0318. 

IBM 1410/7010 Operating System; The System 
Monitor, Form C28-0319. 

IBM 1410/7010 Operating System; Autocoder, Form 
C28-0326. 



Minimum Machine Requirements 

The minimum machine requirements for programs in- 
corporating the iocs are contained in the publication, 
IBM 1410/7010 Operating System; System Generation, 
Form C28-0352. 



Definition of Terms 

Basic terms that appear frequently in this publication 
are defined here for the convenience of the reader. 

Data Record: A collection of related facts, numbers, 
letters, or symbols that are treated as a unit and may 
be processed or produced by a computer. 

Logical Record: A data record. 

Card, Tape, Disk, and Printer Records: One or more 
data records brought together in such a way that they 
may be read or written by a single input/output in- 
struction. 

Physical Record: A card, tape, disk, or printer 
record. 

Data File: A group of data records brought to- 
gether for a specific purpose, such as grouping a com- 
pany's accounts receivable. 

Tape, Disk, Card Read, Card Punch, and Printer 
Files: Data files that are read from or written on, re- 
spectively, tape, disk, card read, card punch, or printer 
input/output devices. 

Input and Output Files: Data files from which data 
records are read ( input ) , or on which data records are 
written (output). 
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Basic Use of The IOCS 



The purpose of this section is to provide the informa- 
tion necessary to write efficient programs that make 
use of the functions of the iocs outlined under "Pur- 
pose of the iocs" in the introduction to this publication. 
It should be noted, however, that the iocs is capable 
of providing additional or expanded functions. These 
additional functions are discussed in a later section 
entitled "Extended Use of the iocs." 



General Information 

Information of a general nature, the understanding of 
which is considered a prerequisite to this discussion of 
a basic use of the iocs, is presented here. The material 
covered includes: record forms acceptable to the iocs, 
standard tape labels, input/output areas, da state- 
ments, blocking and deblocking, work areas and 
indexing, end-of-file determination, and wrong-length- 
record checking. 



IOCS Check List 

Whether the programmer wishes to take advantage 
of the basic functions of the iocs, or the basic functions 
plus selected additional functions, the following con- 
ditions must be met if the iocs is to be used: 

1. The configuration of the Resident iocs must be 
defined at System Generation by means of the iokdf 
macro-instruction and one or more devdf macro-in- 
structions; or by means of the iokdf macro-instruction, 
one or more devdf macro-instructions, and one or 
more dskdf macro-instructions. ( The iokdf, devdf and 
dskdf macro-instructions are covered in the System 
Generation publication. ) 

2. Each data file that is to be processed by the 
object program must be defined by means of a dtf 
statement included in the source program. (The dtf 
statement is discussed later in this publication. ) 

3. Every input/output area that is to be used by the 
object program must be defined by means of an 
Autocoder da (Define Area) statement included in the 
source program. (Input/output areas are discussed 
later in this publication, da statements are covered in 
detail in the Autocoder publication, and discussed, as 
they pertain to the iocs, later in this publication.) 

4. All user-written routines (e.g., end-of-file rou- 
tines ) that are to be referenced by the object program 
must be written and included in the source program. 
( The dtf statement entries that inform the iocs of the 
existence of the various user-written routines, and the 
routines themselves, are discussed later in this pub- 
lication. ) 

5. The specific functions the iocs is to perform 
during execution of the object program must be re- 
quested by means of iocs macro-instructions included 
in the source program. (The iocs macro-instructions 
are discussed later in this publication. ) 



Blocked Records 

Data records should be grouped in blocks when they 
are frequently read or written and are not excessive 
in length, because blocked records can be read and 
written at a faster rate than unblocked records. This 
is because the number of times a tape drive must be 
started and stopped and the number of times disk 
operations must be executed, to read or write a given 
number of data records, is reduced when the records 
are blocked. Furthermore, the reduction in the num- 
ber of tape interrecord gaps and disk record ad- 
dresses permitted by blocked records increases the 
available storage capacity of a reel of tape or track of 
disk storage. 

Blocking and Deblocking 

The iocs is capable of making data records that have 
been read into core storage in blocks available to the 
user's program as individual records (i.e., deblocking 
them ) . 

The iocs is also capable of grouping individual data 
records (i.e., blocking them) for transfer from core 
storage. 

Record Forms Acceptable to the IOCS 

The iocs accepts four forms of data records, under the 
following conditions: 

1. Records of the same file must have the same form, 
although the iocs is capable of handling several files 
each of which uses a different record forrn. 

2. Records moved from one area of core storage to 
another by the iocs must terminate with a record 
mark, or the area from which the record is moved must 
terminate in a group mark with word mark. 

The four forms of data records acceptable to the 
iocs are Form 1, 2, 3, and 4 data records. 



FORM 1 DATA RECORDS 

Form 1 records are unblocked, fixed-length or variable- 
length records. Form 1 records should be used when- 
ever: 

1. Data records are exceptionally long. 

2. Data records use a nonstandard format. 

3. The programmer plans to block data records 
himself prior to transferring them from core storage. 

4. The programmer does not wish to have wrong- 
length-record checks performed on unblocked, vari- 
able-length data records. 

Examples of Form 1 records, as they appear on 
magnetic tape and in disk storage, are shown in 
Figures 1 and 2. 

Note: The disk track formats shown in Figures 2, 4, 
6, and 8 are read or written by the Read/Write Full 
Track With Home Address or the Read/Write Single 
Record instruction. These formats were chosen arbi- 
trarily to simplify the figures. The programmer may 
format his disk tracks to be read or written by any 
1301 read/write instruction. 

MAGNETIC TAPE 
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Figure 1. Form 1 Data Records on Magnetic Tape 
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Figure 3. Form 2 Data Records on Magnetic Tape 



FORM 3 DATA RECORDS 

Form 3 records are identical to Form 1 records, with 
one exception. The first four positions of every Form 3 
record contain a Block Character-Count. This count 
allows the iocs to make wrong-length-record checks. 
When a Form 3 record is placed in an output area for 
transfer from core storage, the programmer must insert 
a group mark with word mark immediately to the 
right of the low-order position of the record, unless the 
low-order position coincides with the end of the output 
area. Examples of Form 3 records, as they appear on 
magnetic tape and in disk storage, are shown in Fig- 
ures 5 and 6. 

Block Character-Count: The Block Character-Count 
is a four-position field that must appear at the begin- 
ning of each Form 3 data record (see Figure 5) and 
at the beginning of each block of Form 4 data records 
(see Figure 7). This field contains an integer (right- 
justified ) that specifies the number of positions of core 
storage required to contain the record or block of 
records. The positions occupied by the Block Char- 
acter-Count and any terminal record marks that ap- 
pear in the record or block of records are included in 
this number. Word marks may not appear over the 
three low-order positions of this field. 



FORM 2 DATA RECORDS 

Form 2 records are blocked, fixed-length records. They 
should be used whenever data records are the same 
length. Examples of Form 2 records, as they appear 
on magnetic tape and in disk storage, are shown in 
Figures 3 and 4. 



FORM 4 DATA RECORDS 

Form 4 records are blocked, variable-length records 
that contain a Record Character-Count. In addition, 
the first four positions of each block of Form 4 records 
contain a Block Character-Count. This record form 
should be used when a file consists of a large number 
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of records that vary considerably in length. When a 
complete block of Form 4 records has been assembled 
in an output area for transfer from core storage, the 
iocs places a group mark with word mark immediate- 
ly to the right of the low-order position of the block. 

Examples of Form 4 records, as they appear on 
magnetic tape and in disk storage, are shown in 
Figures 7 and 8. 

Record Character-Count: The Record Character- 
Count is a field consisting of from one to five positions 
that must appear in every Form 4 data record handled 
by the iocs (see Figure 7). The field contains an in- 
teger (right-justified) that specifies the number of 
positions of core storage required to contain the rec- 
ord. The positions occupied by the Record Character- 



Count and the record mark terminating the record ( if 
any) are included in this number. This field must 
have a word mark over its high-order position, unless 
it is five positions in length. Word marks cannot 
appear over any other position. The low-order position 
of this field must appear at a fixed distance from the 
high-order position of each record in the file, and it 
cannot be signed minus. 
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RECORD FORM SUMMARY 

The four forms of data records acceptable to the 
iocs are summarized in Figure 9. 

Standard Tape Labels 

Optional tape label routines have been included in 
the iocs to ensure that the correct tapes are made 
available to using programs, and to facilitate the main- 
tenance of tape libraries. These tape label routines are 
based on use of 1410 80-character or ibm Standard 
120-Character header and trailer labels. Header 
labels are the first record on each reel of tape, and 
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serve to identify the tape. Trailer labels are, except 
for a tape mark, the last record on each reel of tape. 
They indicate whether or not a reel is the last reel of 
a file. The formats of the 1410 80-character and ibm 
Standard 120-Character header and trailer labels are 
discussed in the material that follows. 

1410 80-CHARACTER TAPE LABELS 

80-Character Temporary Header Labels: An 80-char- 
acter temporary header label followed by a tape mark 
should appear on each reel of tape that is to become 
part of a file that uses 1410 80-character labels. The 
80-character temporary header labels must conform 
to the format shown in Figure 10. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


IHDRb 


Label Identifier 




2 


6-10 


xxxxx 


Reel Serial Number 




3 


11-30 


Blanks 






4 


31-35 


YYDDD 


Creation Date 




5 


36-40 


Blanks 






6 ■ 


41-80 


Miscellaneous 


May be used to include 
pertinent information 


other 



Figure 10. 1410 80-Character Temporary Header Label Format 

Label Identifier. The label identifier ( Field 1 ) con- 
sists of the characters lHDRb. The label identifier indi- 
cates to the iocs that the record containing these 
characters is a tape header label. 

Reel Serial Number. The reel serial number (Field 
2) is a five-digit number that is assigned to the reel 



when it enters the tape library of the using installation. 

Field 3. This is a 20-position field that contains 
blanks. 

Creation Date. The creation date (Field 4) is a 
five-digit number. The first two digits of this number 
specify the year; the remaining digits the day of the 
year this label was placed on the reel. 

Field 5. This is a five-position field that contains 
blanks. 

Miscellaneous. Field 6 can be used to include other 
information relevant to the label. 

1410 80-Character Header Labels: The iocs can re- 
place 80-character temporary header labels with 1410 
80-character header labels during execution of the 
user's object program. The 1410 80-character header 
labels must conform to the format shown in Figure 11. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


IHDRb 


Label Identifier 


2 


6-10 


xxxxx 


Reel Serial Number 


3 


11-15 


xxxxx 


File Serial Number 


4 


16-20 


-xxxb 


Reel Sequence Number 


5 


21-30 


xxxxxxxxxx 


File Identification 


6 


31-35 


YYDDD 


Creation Date 


7 


36-40 


-xxxb 


Retention Period 


8 


41-80 


Miscellaneous 


May be used to include other 
pertinent information 



Figure 11. 1410 80-Character Header Label Format 

Label Identifier. The label identifier ( Field 1 ) con- 
sists of the characters lHDRb. The label identifier indi- 
cates to the iocs that the record containing these 
characters is a tape header label. 
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Reel Serial Number. The reel serial number (Field 

2) is a five-digit number that is assigned to the reel 
when it enters the tape library of the using installation. 

File Serial Number. The file serial number (Field 

3 ) is a five-digit integer that is equal to the reel serial 
number of the first reel of the file. 

Reel Sequence Number. The reel sequence number 
(Field 4) is a three-digit number preceded by a 
hyphen and followed by a blank character. It identifies 
the position within the tape file of this particular reel 
of the file (e.g., -007b appearing in this field would 
indicate that the reel is the seventh reel of the file ) . 

File ^identification. The file identification (Field 
5 ) consists of ten characters, and serves to identify the 
tape file to which the reel belongs. 

Creation Date. The creation date (Field 6) is a 
five-digit number. The first two digits specify the year; 
the remaining digits the day of the year the label was 
placed on the reel. 

Retention Period. The retention period (Field 7) is 
a three-digit number preceded by a hyphen and fol- 
lowed by a blank character. The three-digit number 
is the number of days the file is to be retained after 
the creation date appearing on the same reel. The 
iocs can process retention periods of up to 365 days 
for this type of label. If a file is to be protected beyond 
this time, 999 should be placed in this field. 

Miscellaneous. Field 8 may be used to include other 
information relevant to the label. 

1410 80-Character Trailer Labels: The 1410 80-char- 
acter trailer labels must conform to the format shown 
in Figure 12. 



mark should appear on each reel of tape that is to 
become part of a data file that uses ibm Standard 120- 
Character labels. These temporary header labels must 
conform to the format shown in Figure 13. 



Field No. 


Positions 


Contents 


Description 


1 

2 
3 


1-5 

6-10 
11-80 


lEORb 
lEOFb 
xxxxx 
Miscellaneous 


Trailer-Label Identifier 

Block Coun t 

May be used to include other 

pertinent information 



Figure 12. 1410 80-Character Trailer Label Format 

Label Identifier. The label identifier (Field 1) con- 
sists of the characters 1eofd if the reel is the last reel 
of the file, or lEORb if the reel is not the last reel. 

Block Count. The block count (Field 2) is the num- 
ber of blocks of data records that appear on the reel 
of tape. 

Miscellaneous. Field 3 may be used to include other 
information relevant to the label. 

IBM STANDARD 120-CHARACTER TAPE LABELS 

120-Character Temporary Header Labels: A 120- 
character temporary header label followed by a tape 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


.lHDRb 


Label Identifier 




2 


6-10 


Blanks 






3 


11-15 


YYDDD 


Creation Date 




4 


16-30 


Blanks 






5 


31-35 


xxxxx 


Reel Sequence Number 




6 


36-100 


Blanks 






7 


101-120 


Miscellaneous 


May be used to include 
pertinent information 


other 



Figure 13. ibm Standard 120-Character Temporary Header 
Label Format 



Label Identifier. The label identifier (Field 1) con- 
sists of the characters lHDRb. The label identifier indi- 
cates to the iocs that the record containing these char- 
acters is a tape header label. 

Field 2. This is a five-position field that contains 
blanks. 

Creation Date. The creation date ( Field 3 ) is a five- 
digit number. The first two digits specify the year; the 
remaining digits the day of the year this label was 
placed on the reel. 

Field 4. This is a 15-position field that contains 
blanks. 

Reel Serial Number. The reel serial number (Field 
5) is a five-digit number that is assigned to the reel 
when it enters the tape library of the using installation. 

Field 6. This is a 65-position field that contains 
blanks. 

Miscellaneous. Field 7 can be used to include in- 
formation relevant to the label. 

IBM Standard 120-Character Header Labels: The 
iocs can replace 120-character temporary header labels 
with ibm Standard 120-Character header labels during 
execution of the user's object program. The ibm Stand- 
ard 120-Character header label must conform to the 
format shown in Figure 14. 

IBM Standard 120-Character Trailer Labels: The 
iocs can write ibm Standard 120-Character trailer 
labels at the end of each reel of tape. The format of 
these trailer labels is identical to that of the ibm Stand- 
ard 120-Character header labels shown in Figure 14. 

Label Identifier. The label identifier (Field 1) con- 
sists of the characters lHDRb if the record is a header 
label; lEORb if the record is an end-of-reel trailer 
label; and lEOFb if the record is an end-of-file trailer 
label. 
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Field No. 


Position 


Contents 


Description 


1 


1-5 


IHDRb 








lEORb 


Label Identifier 






lEOFb 






6 


b 


Blank 


2 


7-10 


xxxx 


Retention Period 


3 


11-15 


xxxxx 


Creation Date 


4 


16-25 


xxxxxxxxxx 


File Identification 


5 


26-30 


xxxxx 


File Serial Number 


6 


31-35 


xxxxx 


Reel Serial Number 




36 


b 


Blank 


7 


37-40 


xxxx 


Reel Sequence Number 




41 


b 


Blank 


8 


42-44 


bbb 


Reserved 


9 


45 


X 


Density Indicator 


10 


46 


X 


Checksum Indicator 


11 


47 


X 


Block Sequence Indicator 


12 


48 


X 


Tape Checking/Interpreting 
Technique Indicator 


13 


49 


X 


Tape Data Recording 
Technique Indicator 


14 


50 


X 


Tape Data Processing 
Technique Indicator 


1 15 


51-54 


xxxx 


Creating System 


16 


55 


X 


Record Format 


17 


56-60 


xxxxx 


Record Length 


18 


61-65 


xxxxx 


Block Size 


19 


66 


X 


Checkpoint Indicator 


20 


67-72 


xxxxxx 


Block Count 


21 


73-74 


bb 


Reserved 


22 


75-79 


bbbbb 


Reserved 


23 


80 


b 


Reserved 


24 


81-85 


bbbbb 


Reserved 


25 


86-91 


bbbbbb 


Reserved 


26 


92-100 


bbbbbbbbb 


Reserved 


27 


101-120 


Miscellaneous 


Any other pertinent information 



Figure 14. ibm Standard 120-Character Header/ Trailer 
Label Format 

Retention Period. The retention period (Field 2) 
is a four-digit number ( 0001-9999 ) that represents the 
number of days the file is to be retained after the 
creation date specified in Field 3. 

Creation Date. The creation date (Field 3) is a 
five-digit number. The first two digits of this number 
specify the year, the remaining digits the day of the 
year the file, of which this reel is a part, was created. 

File Identification. The file identification (Field 

4) consists of ten characters that identify the file to 
which the reel of tape belongs. 

File Serial Number. The file serial number (Field 

5) is a five-digit integer equal to the reel serial num- 
ber of the first reel of the file. 

Reel Serial Number. The reel serial number (Field 

6) consists of five alphameric characters, other than 
blank characters, assigned to the reel when it enters 
the tape library of the using installation. 

Reel Sequence Number. The reel sequence number 
(Field 7) is a four-digit number that identifies the 
position within the tape file of this particular reel 
(e.g., 0007 appearing in this field would indicate that 
this reel is the seventh reel of the file ) . 

Reserved. Field 8 is left blank. It is reserved for 
future ibm programming use. 



Density Indicator (Field 9), Check Sum Indicator 
(Field 10), Block Sequence Indicator (Field 11), 
Tape Checking/Interpreting Indicator (Field 12), 
Tape Data Recording Technique Indicator (Field 13), 
and Tape Data Processing Technique Indicator ( Field 
14). Fields 9-14 are not applicable. The iocs enters a 
zero in each. 

Creating System. Field 15 is used to specify the 
Data Processing System on which the file was created. 
The iocs enters 1410 or 7010 (whichever is applicable) 
in this field. 

Record Format. Field 16 is used to indicate the data 
record form used by the file. Form 1, 2, 3, or 4 records 
are represented in this field by B, F, W, or X, respec- 
tively. 

Record Length. Field 17 is used to specify data 
record length. For fixed-length data records, the iocs 
enters the number of characters in each record. For 
variable-length records, the iocs enters the number of 
characters in the largest possible record. 

Block Size. Field 18 is used to specify block size. 
For blocked, fixed-length records, the iocs enters 
the number of data records in each block. For blocked, 
variable-length records, the iocs enters the maximum 
number of characters that can be contained in a block. 
If the file consists of unblocked records, this field 
contains zeros. 

Checkpoint Indicator. This indicator (Field 19) is 
not applicable. The iocs enters zero in this field. 

Block Count. Field 20 is used to specify the block 
count (i.e., the number of blocks of records on the 
reel). The block count does not include header labels, 
trailer, or tape marks. The block count is of signifi- 
cance only in a trailer label. In header labels this field 
is left blank. 

Reserved. Fields 21 through 26 are reserved for 
future ibm programming use. The iocs leaves these 
fields blank. 

Miscellaneous. Field 27 may include any informa- 
tion relevant to the label. 

Standard Tape Formats 

When a tape file uses standard labels, the iocs can 
accept only the tape formats shown in Figure 15. 



Format A 


Format B 


120 Character Header Label 


80 Character Header Label 


Tape Mark 


Data 


Data 


Tape Mark 


Tape Mark 


80 Character Trailer Label 


120 Character Trailer Label 


Tape Mark 


Tape Mark 





Figure 15. Tape Formats Acceptable to the iocs 
( Standard Labels ) 
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Input/Output Areas 

To read data records from or write data records on a 
data file, at least one input/output area must be pro- 
vided in core storage to contain the data records that 
have been read or that are to be written. 

The iocs permits the programmer to specify more 
than one input/output area for each file so that he 
may take advantage of the Processing Overlap special 
feature. 

The number of input/output areas used for each file 
can have a direct bearing on the efficiency of the pro- 
gram. When selecting the number of areas that are to 
be used, the programmer should consider the follow- 
ing: 

1. Whether the program is input/output limited. If 
the program has to wait for input/output operations 
to provide records for processing or to write records 
that have already been processed, the use of multiple 
input/output areas can help reduce the running time 
of the program. 

2. The number of files in the program. If there are 
many files, the number of input/output areas specified 
per file may have to be limited to conserve core 
storage. 

3. The activity of the file. When the core storage 
available for input/output areas is limited, the major 
portion of that core storage should be allocated to 
areas that are to be used by the most active files. 

Single and multiple input/output areas are dis- 
cussed separately, in the material that follows, to aid 
the user in selecting the most suitable number of areas 
for each file. 

ONE AREA 

When one input/output area is specified for a file, the 
program must ordinarily wait until an input/output 
operation has been executed before processing the 
next record. For this reason, the programmer should 
normally avoid specifying a single area unless one or 
more of the following conditions apply: 

1. Core storage is limited by other program require- 
ments. 

2. The file does not contain many records. 

3. The file is seldom referenced by the program. 

4. The file is read from or written on a unit-record 
input/output device. 

5. The iocs does not allow the use of more than one 
area. (Any such restriction is noted in the appropriate 
section of this manual. ) 

MULTIPLE AREAS 

The pause to execute an input/output operation noted 
above can largely be eliminated by using multiple 



areas. When processing is completed in one area, the 
program begins processing the data record or records 
in the next area. At the same time, the iocs reads into, 
or writes out of the area in which processing was just 
completed. Under these conditions processing is virtu- 
ally continuous. 



DA (Define Area) Statements 

Autocoder da statements are used to reserve and define 
all input/output areas used by programs incorporating 
the iocs, da statements used to define input/output 
areas associated with unit-record or tape files (Figure 
16 ) must have the letter G preceded by a comma ( , G) 
as the last entry in the operand field of the header 
line. This causes a group mark with word mark to be 
placed immediately to the right of the low-order 
position of the area. An example of the area this state- 
ment will reserve in core storage is shown in Figure 
17. 
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Figure 16. Unit-Record/ Tape da Statement 
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Figure 17. Input/Output Areas ( Unit-Record/Tape Files ) 



Work Areas and Indexing 

If a file consists of blocked records or uses multiple 
input/output areas, the programmer must decide 
whether it is more economical to process each data 
record in the input/output area(s) associated with 
the file by indexing the area(s), or to move each 
record into a work area and process it there. A general 
rule is available to guide the programmer. The number 
of positions of core storage occupied by an input/out- 
put area associated with the relevant file should be 
divided by four. If the result is less than the number 
of indexed references required to process the data in 
that area, a work area should be used. If the result is 
greater, indexing should be used. 
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End of File 

The iocs determines that the end of a tape file has 
been reached when any of the conditions noted below 
has occurred. 

FILE TYPE CONDITION 

Tape Input The file makes use of standard trailer labels, 
and a Ieofd trailer label identifier has been 
encountered on a reel of the file. 

Tape Input The file does not use labels, and a tape mark 
has been encountered on a reel of the file. 

Wrong-Length Records 

The iocs is capable of detecting wrong-length-record 
conditions. It performs this function, depending on 
the type of file, as follows : 

1. For disk files, the iocs checks the length of the 
record, as specified on the appropriate disk format 
track, against the size of the input/output area into 
which the record is read or from which it is written. 

2. For input files that consist of Form 1 or Form 2 
data records, a check is made to determine whether 
the interrecord gap following the record or block of 
records coincides with the group mark with word mark 
that terminates the input area into which the record 
or block was read. If the interrecord gap occurs before 
or after the group mark with word mark, a wrong- 
length-record condition is indicated. 

3. For tape files that consist of Form 3 or Form 4 
data records, the iocs references the Block Character- 
Count that precedes the relevant record or block of 
records to perform the wrong-length-record check. 
(The iocs cannot make wrong-length-record checks 
for tape files consisting of unblocked, variable-length 
records that do not include a Block Character-Count. ) 

4. For unit-record files, the iocs determines if the 
length of the relevant input/output area coincides 
with the size of the appropriate buffer in the ibm 1414 
Input/Output Synchronizer. 



DTF Statement 

The primary function of the dtf statement is to define 
the characteristics of the data file for which it was 
written. Each dtf statement consists of five or more 
entries, These entries may be broken down into those 
required for a basic use of the iocs and those required 
for an extended use of the iocs. The basic dtf entries 
are discussed in this section; the extended dtf entries 
are discussed in a later section. 

GENERAL FORMAT 

The dtf statement is written in the following manner. 
The code dtf is entered in the operation field of one 
line of the Autocoder coding sheet, and the name of 
the file that is to be defined is entered in the operand 



field of the same line. The entries relevant to this file 
are then listed on succeeding lines of the coding sheet. 
These entries must be selected from the entries dis- 
cussed in this section or in the section on the extended 
use of the iocs. As each entry is included, the opera- 
tion field of the affected line of the coding form must 
be left blank. Operands of the same entry must be 
separated by commas, unless otherwise noted in the 
discussion of that entry. Labels included as operands 
of an entry may be address modified. 

All entries may be followed by comments. These 
comments must be separated from the entries by a 
minimum of two consecutive blanks. 

There are no restrictions on where the dtf statement 
defining a particular file must appear in the user's 
source program. 

A dtf statement cannot be written for a file that 
refers to an input/output unit that has been designated 
the system's Standard Input Unit (siu), Alternate 
Input Unit (aiu), Standard Punch Unit (spu), Stand- 
ard Print Unit ( spr ) , or System Operating File ( sof ) . 
(See the System Monitor publication for a discussion 
of these units. ) 

Basic DTF Entries 

The dtf entries required to make a basic use of the 
iocs are as follows: 

DTF Header Line RECSIZE 

SYMUNIT INDEX 

FILEFORM PADCHAR 

BLOCKSIZE ERRCHECK 

IOAREAS ERROPTNS 

EOFADDR RWDOPTNS 

MODE LABEL 

ORDER CHECK 

DTF HEADER LINE 

This entry is required. It must appear as the first 
entry of every dtf statement. It consists of the code 
dtf entered in the operation field of the coding sheet 
and the name of the data file that is to be defined 
entered in the operand field ( see Figure 18 ) . 

The name of the file cannot be a linkage symbol. 
( Linkage symbols are discussed in the System Monitor 
publication. ) 
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Figure 18. dtf Header Line 
SYMUNIT 

This entry is required. The first operand of this entry 
indicates the type of input/output device used by the 
file. The first operand must be one of the following: 
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OPERAND EXPLANATION 

1301 The file is read from or written in 1301 Disk 

Storage. 
TAPE The file is read from or written on magnetic 

tape units.* 
READER The file is read from a 1402 Card Read 

Punch or a 1442 Serial Card Reader. 
PUNCH The file is punched on a 1402 Card Read 

Punch. 
PRINTER The file is printed on a 1403 Printer. 
1011 The file is read from a 1011 Paper Tape 

Reader. 

The second operand of the symunit entry is the 
name of the symbolic unit that is to be used for the 
file. This name is used to assign a physical unit to the 
file. (See the System Monitor publication for discus- 
sions of symbolic units and physical units.) An ex- 
ample of how this entry is coded is shown in Figure 
19. 
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Figure 19. symunit Entry 



FILEFORM 



This entry is required. The operand of this entry indi- 
cates the data record form used by the file. The 
operand must be 1, 2, 3, or 4 to indicate, respectively, 
Form 1, 2, 3, or 4 data records. An example of how 
this entry is coded is shown in Figure 20. 
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IOAREAS 

This entry is required for a basic use of the iocs. It is 
used to indicate to the iocs which input/output areas 
are to be associated with the file. 

The ioareas entry may have a minimum of one, and 
a maximum of three operands. Each operand is the 
label of an input/output area that is to be associated 
with the file. Figure 22 shows an example of how 
this entry is written. Every input/output area whose 
label appears as an operand of this entry must be 
defined by an Autocoder da statement. (If the pro- 
grammer wishes to use more than three input/output 
areas to process a file, he must utilize the dtf filelist 
entry. This entry is discussed under "Extended Use 
of the iocs.") 
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Figure 22. ioareas Entry 



EOFADDR 



This entry is required for all tape and unit-record 
input files. The operand of the eofaddr entry is the 
label of the end-of-file routine the programmer has 
provided for the file. (This routine is entered when- 
ever the iocs determines that an end-of-file condition 
has occurred on the file. ) An example of how this entry 
is coded is shown in Figure 23. 
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Figure 20. fileform Entry 



Figure 23. eofaddr Entry 



BLOCKSIZE 

This entry is required. The operand of the blocksize 
entry is an integer equal to the number of positions of 
core storage occupied by any one input/output area 
associated with the file. The group mark with word 
mark that terminates the area, the eight-digit disk 
track address, and eight-digit disk record address (if 
any) that precede the area are not included in this 
integer. Figure 21 shows an example of how this entry 
is written. 



MODE 

This entry is required for files that are read or written 
in Load mode. It is also required for tape files that 
are read or written in odd parity. Two of the possible 
operands of the mode entry are load and odd. The 
load operand indicates that the file is to be read or 
written in Load mode. The odd operand indicates the 
file is to be read or written in odd parity. These 
operands may be entered in any order, and either 
operand may be omitted if it is not appropriate. See 
Figure 24 for an example of how this entry is written. 
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Figure 21. blocksize Entry 
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Figure 24. mode Entry 
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ORDER 

This entry is required for all files except tape files, 
unless otherwise noted in the discussion of operands 
that follows. The operand of the order entry supplies 
the iocs with the low-order character of the x-control 
field of the input/output instruction required to 
process the file. It must be one of the following: 

OPERAND EXPLANATION 

0, 1, or 2 The file is an input card file and 0, 1, or 2 is 
the stacker into which cards read from the file 
are to be selected. If 1 is the appropriate oper- 
and the entry is optional. 

0, 4, or 8 The file is an output card file and 0, 4, or 8 is 
the stacker into which the punched cards that 
belong to the file are to be selected. If 4 is the 
appropriate operand, the entry is optional. 

The file is a 1403 Printer file and the Write A 
Line instruction is to be used to process the file. 
If this operand is appropriate, the entry is op- 
tional. 

1 The file is a 1403 Printer file and the Write 
Word Marks instruction is to be used to process 
the file. (The Write A Line and Write Word 
Marks instructions are explained in the publica- 
tion, IBM 1410 Principles of Operations, Form 
A22-0526. ) 

1 The file is a 1301 disk file that is to be read/ 
written by means of the Read/Write Single 
Record instruction. 

2 The file is a 1301 disk file that is to be read/ 
written by means of the Read/Write Full Track 
Without Record Addresses instruction. If this 
operand is appropriate, the entry is optional. 

5 The file is a 1301 disk file that is to be read/ 
written by means of the Read/Write Full Track 
With Home Address instruction. 

6 The file is a 1301 disk file that is to be read/ 
written by means of the Read/Write Full Track 
With Addresses instruction. 

@ The file is a 1301 disk file that is to be read/ 
written by means of the Read/Write Cylinder 
instruction. 

The 1301 Disk Storage input/output instructions are 
discussed in detail in the publication, IBM 1301 Disk 
Storage with IBM 1410 and 7010 Systems, Form A22- 
6670. 

An example of how the order entry is coded, is 
shown in Figure 25. 
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Figure 25. order Entry. 
RECSIZE 

This entry is only required for files that consist of 
Form 2 or Form 4 records. If the file consists of Form 2 



records, the operand of the recsize entry specifies the 
number of characters that appear in each data record 
of the file. If the file consists of Form 4 records, the 
operand of the recsize entry specifies the position, 
in each data record, of the low-order digit of the 
Record Character-Count. (The first position of a Form 
4 tape record is considered 1, not 0, when determining 
the position of the low-order digit of the Record Char- 
acter-Count. ) An example of how this entry is coded 
is shown in Figure 26. 
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Figure 26. recsize Entry 



INDEX 



This entry is required for a basic use of the iocs, if: 
( a ) the file uses blocked records or multiple input/out- 
put areas, and (b) the programmer plans to access 
data records in the input/output areas associated with 
the file. 

The operand of the index entry is X1-X12, depend- 
ing on the index register (1-12) the programmer 
wishes to utilize. If this entry is included, and the file 
is an input file, the iocs places, in the index register 
specified, the high-order address of the data record 
currently available to the using program. ( See Figure 
27.) 

If this entry is included and the file is an output 
file, the iocs places, in the index register specified, the 
high-order address of that portion of the current out- 
put area that is available to the using program. (See 
Figure 28. ) 

An example of how this entry is coded is shown 
in Figure 29. 

PADCHAR 

This entry is not required. It is relevant only if the file 
consists of blocked, fixed-length records (i.e., Form 2 
data records). The padchar entry (Figure 30) causes 
the iocs to pad the last block of the file with the char- 
acter entered as the operand of this entry. The char- 
acter entered may be any character except =K^> *. $■> 
or rrs , unless the file is to be sorted by the Generalized 
Tape Sort which is an integral part of the 1410/7010 
Operating System. In this case, the character entered 
as the operand of this entry must be the character 9. 
If this entry is omitted, the iocs pads with blank 
characters. (Blank characters are also acceptable to 
the Generalized Tape Sort. ) 
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Figure 27. dtf index ( Input Files ) 
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Figure 28. dtf index ( Output Files ) 
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Figure 29. index Entry 
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Figure 30. padchar Entry 
ERRCHECK 

This entry is not required. It may be used to cause the 
iocs to check for wrong-length records and/or to 
execute Write Disk Checks. The operands of the 
errcheck entry, and the operations those operands 
cause the iocs to perform, are as follows: 

OPERAND OPERATION 

WLR This operand causes the IOCS to check for 

wrong-length records. (It is recommended that 
this operand be specified for all input files, all 
unit-record output files, and all tape output files 
that consist of Form 3 or Form 4 records.) If 
this operand is omitted, the IOCS does not in- 
terrogate the Wrong-Length-Record channel 
status indicators. 

WDC This operand causes the IOCS to execute a 

Write Disk Check after every Write Disk op- 
eration performed on the file. 

One or both of these operands can be entered, and 

in any order. An example of how this entry is coded 

is shown in Figure 31. 
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Figure 31. errcheck Entry 
ERROPTNS 

This entry is not required. It should appear only if 
the file is an input file. It allows the programmer: (a) 
to accept all records read by input operations executed 
on the file that resulted in error conditions which the 
iocs error procedures could not correct, or (b) to skip 
such records. The operands of this entry are: 

OPERAND FUNCTION 

ACCEPT This operand causes the IOCS to handle all 
uncorrectable, erroneous records that occur 
on the file as if they were error free (i.e., re- 
lease them to the using program as the IOCS 
would a record read into core storage with- 
out error ) . 

SKIP This operand causes the IOCS to read the 

next logical record from the file into the in- 
put area that contains the uncorrectable, er- 
roneous record, thereby destroying that 
record. 



If this entry is omitted, the iocs processes erroneous 
records as if they were error free. 

Each of the operands discussed excludes the other. 
For this reason, only one may be specified in the same 
erroptns entry. Figure 32 shows an example of how 
this entry is coded. 
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Figure 32. erroptns Entry 



RWDOPTNS 

This entry is not required. It is of significance only if 
the file is a tape file. This entry allows the program- 
mer to specify which reels of the file (if any) are to 
be rewound, rewound and unloaded, or backspaced — 
and at what point in the using program this action is 
to be taken. 

The operands of this entry indicate what action is 
to be taken. The operand -fields in which these op- 
erands appear indicate which reels of the file are to 
be acted upon and the time at which this action (if 
any) is to be taken. The four operands that can appear 
in the operand fields of this entry are: 

OPERAND ACTION 

R This operand causes the IOCS to rewind the 

tape reels indicated, at the time indicated. 

U This operand causes the IOCS to rewind and 

unload the tape reels indicated, at the time 
indicated. 

B This operand causes the IOCS to backspace 

the tape reels indicated, at the time indi- 
cated. 

N This operand causes the IOCS to take no 

action on the tape reels indicated, at the 
time indicated. 

The four operand fields of this entry are: 

OPERAND 

FIELD AFFECTED REELS/TIME OF ACTION 

First The first reel of the file is to be acted upon 

at the time the file is opened. 
Second Each reel of the file, except the first, is to be 

acted upon at the beginning of the reel. 
Third Each reel of the file, except the last, is to be 

acted upon at the end of the reel. 
Fourth The last reel of the file is to be acted upon 

at the time the file is closed. 

If this entry is included, all four operand fields 
must appear. They must not be separated by commas. 

If the file is a single-reel file, the second and third 
operand fields should contain N. 

If this entry is omitted, and the file is a tape file, 
the iocs rewinds each reel of the file at the beginning 
and end of each reel. 
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An example of how this entry is coded is shown in 
Figure 33. 
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Figure 33. rwdoptns Entry 



LABEL 



This entry is not required. It is relevant only if the 
file is a tape file that uses labels. The label entry 
provides the iocs with the following information: 

1. Whether the file uses 80-character or 120-char- 
acter labels. 

2. Whether the labels used by the file are standard 
( i.e., 1410 80-character or ibm Standard 120-Character 
labels ) or nonstandard. 

3. The file serial number, file identification, reten- 
tion period, creation date, and reel sequence number 
of the first reel of the file, if the file uses standard 
labels. 

The operands and operand fields of the label entry 
are as follows : 



OPERAND 
FIELD 

First 



OPERAND 

80, if the file uses 80-character labels; 120 
if the file uses 120-character labels. 
Second The five-digit file serial number, if the file 

uses standard tape labels; NONSTD, if the 
file uses nonstandard labels. (If NONSTD is 
entered here, the rest of the operand fields 
of this entry that follow this field are left 
blank. 

Third The file identification. If fewer than ten 

characters are entered, the IOCS left-justi- 
fies these characters and pads with blanks to 
obtain a ten-character file identification. 

Fourth The three-digit (80-character labels) or the 

four-digit (120-character labels) retention 
period. 

Fifth The five-digit creation date. 

Sixth The three-digit (80-character labels), or the 

four-digit (120-character labels) reel se- 
quence number. 

If the file uses standard labels all six of the operand 
fields discussed must appear in order. If the program- 
mer does not wish to enter the indicated operand in a 
particular operand field, he may omit that operand. 
However, the comma that would normally separate 
the omitted operand from the next operand (if any) 



must be included. An example of how this entry is 
written is shown in Figure 34. 

check 

This entry is required only if the file uses labels and 
the iocs is to check all or part of these labels. This 
entry indicates to the iocs what portions of these labels 
are to be checked. If this entry is omitted, the iocs 
does not check any portion of the labels used by the 
file. The operands, the label fields they cause the iocs 
to check, and the file type and label type affected by 
these operands are as follows : 



OPERAND 

SER 

ID 

SEQ 

DAT 
RET 



CNT 
ALL 



LABEL FIELD 

File serial 

number 

File 

identification 

Reel sequence 

number 

Creation date 

Retention 

period 



Block count 
All the above 



FILE 
TYPE 

Input 

Input 

Input 
Input 



LABEL 
TYPE 



METHOD OF 
CHECKING 



Header Direct Compare* 

Header Direct Compare* 

Header Direct Compare* 

Header Direct Compare* 1 



Output Header Old header creation 
date + retention 
period < current 
date 

Input Trailer Direct Compare** 



* Information provided by dtf label entry, updated by the 
iocs where applicable, is compared against information read 
from the relevant label by the iocs. 

These operands can be entered in any order. If the 
operands ret or all are omitted, output file header 
labels are not read before creation of new header 
labels, and the reel serial number fields in the new 
output header labels contain blanks. The reason for 
this is that the reel serial number for new output 
headers are taken from the old output headers, which, 
in this case are not read. An example of how this entry 
is coded is shown in Figure 35. 
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Figure 35. check Entry 

Sample DTF Statement 

The basic dtf statement for a representative tape file 
(i.e., a file that consists of Form 2 data records, uses 
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Figure 34. label Entry 
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Line 
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Figure 36. Representative dtf Statement 



1410 80-character labels, and is read or written in 
Move mode, even parity ) is shown in Figure 36. 



IOCS Macro-Instructions 

The iocs macro-instructions are Autocoder statements 
entered in the user's source program. When these 
macro-instructions are encountered by the Autocoder 
processor, they cause the processor to produce 1410 or 
7010 machine-language instructions in the user's object 
program. These machine-language instructions cause 
the iocs to perform one or more of the functions of 
which it is capable. 

The iocs macro-instructions may be divided into 
those which cause the iocs to perform the basic func- 
tions discussed in the introduction to this publication 
and those which cause the iocs to perform additional 
or extended functions. The basic iocs macro-instruc- 
tions are covered in the material that follows. The 
extended iocs macro-instructions are discussed under 
"Extended Use of the iocs." 

Note: All iocs macro-instructions destroy the status 
of the High, Low, Equal and Zero Balance Indicators, 
but do not affect the arithmetic overflow or divide 
overflow indicators. 

Basic IOCS Macro-Instructions 

The basic iocs macro-instructions are: 
IOCTL OPEN, INPUT (Open Input File) 
IOCTL OPEN, OUTPUT (Open O'utput File) 
GET FILE (Make Next Logical Record Available) 
GET FILE TO WORK (Make Next Logical Record Avail- 
able and Move to WORK) 
GET FILE TO FILE ( Make Next Logical Record Available 

and Move to Output Area) 
PUT FILE (Write Logical Record) 



PUT WORK TO FILE (Move from WORK and Write 

Logical Record) 
PUT FILE TO FILE (Move from Input Area and Write 

Logical Record) 
IOCTL CLOSE, INPUT (Close Input File) 
IOCTL CLOSE, OUTPUT (Close Output File) 

General Functions 

Each of the basic iocs macro-instructions causes the 
iocs to perform one or more general functions. These 
functions are discussed in the material that follows. 

IOCTL OPEN 

The ioctl open macro-instructions cause the iocs to 
perform the following functions: 

1. Link with the System Monitor to assign input 
and output files to the physical units specified for 
those files in the appropriate dtf symunit entries and 
asgn cards. (The asgn card is discussed in the System 
Monitor publication. ) 

2. Rewind, rewind and unload, backspace, or take 
no action on the first reel of tape input and output 
files, according to the information supplied by the 
relevant dtf rwdoptns entries (if any). 

3. Read and check the header labels of tape input 
and output files, according to the information supplied 
by the appropriate dtf label and check entries. 

4. Make the first output area associated with output 
files available to the using program, and place the 
high-order address of the output areas made available 
in the index registers specified by the relevant dtf 
index entries ( if any ) . 

5. Force the first get macro-instruction issued 
against input files to fill the first input area associated 
with those files, and schedule read operations to fill 
any additional input areas associated with those files. 
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GET 

The get macro-instructions cause the iocs to perform 
the following functions: 

1. Make the next logical record of the indicated file 
available to the using program in the area specified; 
deblocking the record when necessary. 

2. Schedule read operations to fill those input areas 
associated with the indicated files (if any) that have 
been processed by the using program. 

3. Begin processing any end-of-reel condition en- 
countered on the indicated file. 

4. Cause an exit to be taken to the end-of-file 
routine provided for the indicated file by the user, if 
the iocs determines that an end-of-file condition exists 
on that file. 

PUT 

The put macro-instructions cause the iocs to perform 
the following functions: 

1. Prepare the current output area of the affected 
file to receive the next logical record of the file. 

2. Block data records in the current output area of 
the affected file. 

3. Schedule output operations that write on the 
affected file the data record(s) in the current output 
area of that file. 

4. Begin processing end-of-reel conditions encoun- 
tered on the affected file by branching to the iocs 
Output End-Of-Reel routine. 

5. Exit to the user's end-of-file routine for the 
affected file, if that file is a disk file and the iocs 
determines that an end-of-file condition exists on 
that file. 

IOCTL CLOSE 

The ioctl close macro-instructions cause the iocs to 
perform the following functions: 

1. Ensure completion of all requests pending for 
input/output operations against input and output files. 

2. Pad incomplete blocks of Form 2 records if the 
affected files are output files. 

3. Write all remaining records or blocks of records 
(i.e., those records or blocks that have not already 
been written) from the output areas of output files. 

4. Write a tape mark on tape output files following 
the last data record or block of data records on those 
files. 

5. Assemble and write trailer labels for tape output 
files that include a dtf label or exten entry in the dtf 
statements used to define those files. 

6. Rewind, rewind and unload, backspace, or take 
no action on the last reel of tape input and output 
files, according to the information supplied by the ap- 
propriate dtf rwdoptns entries (if any). 



Using the Basic Macro-Instructions 

Figure 37 illustrates the use of ioctl open, get, put, 
and ioctl close. 




Figure 37. Basic Macro-Instructions 

Coding the Basic Macro-Instructions 

The basic iocs macro-instructions are coded as noted 
in the paragraphs that follow. 

ioctl open, input 

This macro-instruction is used to open input data files. 
The names of the input files that are to be opened 
appear as the operands of this macro-intruction. A 
maximum of eight files may be opened by each ioctl 
open,input macro-instruction. An example of how 
this macro-instruction is coded is shown in Figure 38. 
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Operation 
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Figure 38. ioctl open, input 



IOCTL OPEN, OUTPUT 

This macro-instruction is used to open output data 
files. The names of the output files that are to be 
opened appear as the operands of this macro-instruc- 
tion. A maximum of eight files may be opened by 
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each ioctl open, output macro-instruction. Figure 39 
shows an example of how this macro-instruction is 
coded. 



Label 



Operation 
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Figure; 39. ioctl open, output 
GET FILE 

The get file macro-instruction makes the next logical 
record from the affected file (e.g., the file labeled 
infile in Figure 40) available to the using program. 
If a single input area has been specified for the file, 
the record is made available in that area. If multiple 
input: areas are specified, the record is made available 
in the area with which the iocs is currently working. 
An example of how this macro-instruction is coded is 
shown in Figure 40. 
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Figure 40. get file 



areas, or if the iocs is to build blocks of records in 
the output area( s ) of that file. 

If the affected input and output files consist of 
Form 4 data records, the next record is not immediate- 
ly moved into the current output area. Under these 
conditions the iocs first checks the current output area 
of the affected output file. If the area contains enough 
positions to absorb the record, the iocs then moves 
the record into the output area. If there are not 
enough positions, the contents of the output area are 
written on the affected output file, and the data record 
is moved into the output area as the first record of a 
new block. 

In either case, a put file must be issued against 
outfile to cause the iocs: (a) to account for the 
record just moved into the output area, and (b) to 
select the next available portion of the output area. 

Note: If this macro-instruction is used with two 
files; one that consists of Form 3 records and one that 
consists of Form 4 records: (a) the dtf recsize entry 
for the Form 4 file must have the character 4 as its 
operand, and (b) the input area(s) associated with 
the Form 3 file must have a word mark over its high- 
order position. 

An example of how this macro-instruction is coded 
is shown in Figure 42. 



GET FILE TO WORK 

The get file to work macro-instruction, in addition to 
the functions described under "get file," causes the 
next logical record to be moved into an area other 
than an input area associated with the file (e.g., the 
area labeled work in the example of how this macro- 
instruction is coded, shown in Figure 41 ) . 
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Figure 41. get file to work 



get file to file 

The get file to file macro-instruction, in addition to 
the functions described under "get file," causes the 
next logical record to be moved into an output area. 
If a single output area is specified for the affected file 
(e.g., the file labeled outfile in Figure 42), the record 
is moved into that area. If multiple output areas are 
specified, the record is moved into the area with which 
the iocs is currently working. 

To use get file to file, the programmer must 
specify the dtf index entry for the affected output 
file, if the affected output file uses multiple output 
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Figure 42. get file to file 



put file 

put file causes the iocs to write a data record, or a 
complete block of data records, on the affected file 
(e.g., the file labeled outfile in Figure 43). If a 
single output area was specified for the file, the record 
or block is written from that area. If multiple output 
areas were specified, the record or block is written 
from the output area with which the iocs is currently 
working. This macro-instruction can be used with files 
consisting of Form 4 records only when used in con- 
junction with put file, form4. (See "put file, form4," 
under "Extended Use of the iocs.") An example of 
how this macro-instruction is coded is shown in Fig- 
ure 43. 
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Figure 43. put file 
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PUT WORK TO FILE 

put work to file, in addition to the functions des- 
cribed under "put file," causes a data record in an 
area other than an input/output area (e.g., the area 
labeled work in Figure 44) to be moved to the cur- 
rent output area of the affected file (e.g., the file 
labeled outfile). An example of how this macro- 
instruction is coded, is shown in Figure 44. 
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Figure 44. put work to file 



PUT FILE TO FILE 



put file to file, in addition to the functions de- 
scribed under "put file," causes the next logical record 
in the current input area of the affected input file 
(e.g., the file labeled infile in Figure 45) to be 
moved into the current output area of the affected 
output file (e.g., the file labeled outfile in Figure 
45). 

Note: If this macro-instruction is used with two 
files; one that consists of Form 3 records and one that 
consists of Form 4 records: (a) the dtf recsize entry 
for the Form 4 file must have the character 4 as its 
operand, and (b) the input/output area(s) associ- 
ated with the Form 3 file must have a word mark 
over its high-order position. 

To use put file to file, the programmer must 
specify the dtf index entry for the affected input file, 
if that file uses multiple input areas or consists of 
blocked records. 

An example of how this macro-instruction is coded 
is shown in Figure 45. 
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Figure 45. put file to file 
IOCTL CLOSE, INPUT 

This macro-instruction is used to close input data files. 
The names of the input files that are to be closed 
appear as the operands of this macro-instruction. A 
maximum of eight files may be closed by each ioctl 
close,input macro-instruction. Figure 46 shows an 
example of how the macro-instruction is coded. 
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Operation 
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Figure 46. ioctl close, input 
IOCTL CLOSE, OUTPUT 

This macro-instruction is used to close output data 
files. The names of the output files that are to be 
closed appear as the operands of this macro-instruc- 
tion. A maximum of eight files may be closed by each 
ioctl close, output macro-instruction. Figure 47 
shows an example of how this macro-instruction is 
coded. 
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Figure 47. ioctl close, output 

Note: No get or put macro-instruction should be 
issued against a file before the file is opened or after 
the file is closed by the appropriate ioctl macro- 
instruction. 
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Extended Use of the IOCS 



This section provides the information necessary to 
make use of the additional or extended capabilities of 
the iocs. These capabilities enable the iocs to: 

1. Use additional input/output areas to process a 
file. ( See the dtf ioareas, and filelist entries. ) 

2. Provide exits to user-written error, service and 
tape label routines. (See, respectively, the dtf 

ERRADDR, INTADDR, LINEl, LINE2 and LINEl ABOVE 

entries, and the discussions of user-written error, 
service, and tape label routines. ) 

3. Allow one File Table Extension to be used for 
more than one file. ( See the dtf exten entry. ) 

4. Provide deferred forms of the get and put macro- 
instructions. (See get file, defer and put file, defer.) 

5. Provide an additional method of writing block- 
ed, variable-length records on output files. (See the 
dtf length entry and put file, form4. ) 

6. Alter the stacker into which punched cards are 
to be selected during execution of the object program. 
(See put FiLE,d; put work to FiLE,d; and put file 

TO FILE,d. ) 

7. Release partially processed blocks of data re- 
cords. ( See IOCTL relse. ) 

8. Force end-of-reel conditions. ( See ioctl feor. ) 

9. Write checkpoints. ( See ioctl chkpt. ) 

10. Write specified areas of core storage on the 
console printer. ( See ioctl type, area and ioctl type, 

AREA, DEFER. ) 

11. Perform certain input/output unit control func- 
tions, i.e., the rewinding or rewinding and unloading 
of tape reels. (See the unctl macro-instructions.) 



Extended DTF Entries 

The extended dtf entries may be broken down into 
basic entries with additional or extended operands 
and purely extended entries. These entries are listed 
below and discussed in the material that follows. 



mode 



BASIC PLUS 

ADDITIONAL OPERAND(s) 

MODE 
ORDER 
IOAREAS 
ERRCHECK 



EXTENDED 

ERRADDR 

LENGTH 

INTADDR 

LINEl 
LINE2 
LINEl ABOVE 

EXTEN 
FILELIST 



In addition to the operands discussed previously in 
this publication, a third operand may be included in 
this entry. This operand may be any Autocoder data 
move instruction mnemonic (e.g., mrcg). Figure 48 
shows an example of how this entry is coded. 

If the file is a Load mode file, all data move in- 
structions generated as part of get or put macro- 
instruction calling sequences (i.e., the coding gen- 
erated by a get or a put) that reference the file, are 
normally assembled as mrcwm move instructions. If 
the file is a Move mode file, all such data move instruc- 
tions are normally assembled as mrcm move instruc- 
tions. If the third operand of the mode entry is 
included, the Autocoder mnemonic entered as this 
operand is substituted for the move instruction nor- 
mally assembled (i.e., mrcwm or mrcm). 

If the third operand is included and one or both 
of the other operands (i.e., load and odd) are omitted, 
the comma(s) that would normally separate the 
omitted operand(s) from the next operand must be 
retained. ( See Figures 49 and 50. ) 
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Figure 48. mode Entry (Third Operand ] 
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Figure 49. mode Entry (odd Omitted) 
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Figure 50. mode Entry (load and odd Omitted! 



ORDER 



The following characters, in addition to those dis- 
cussed previously, may appear as the operand of this 
entry: 
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OPERAND EXPLANATION 

9 The file is an input card file and the stacker 

into which cards read from the file are to be 
selected is specified during execution of the 
program by the UNCTL FILE,SSF,d macro- 
instruction. (If this operand is used, only 
one input/output area may be specified in 
the DTF IOAREAS entry.) 

7 The file is a disk file and the Write Format 
Track instruction is to be generated for the 
file. 

Note: The following entries are not specif- 
ically prohibited. However, it should be 
noted that their usefulness is limited. 
4 The file is a 1301 disk file and the Prevent 

Seek Complete instruction is to be generated 
for the file. 

8 The file is a disk file and the Set Access In- 
operative instruction is to be generated for 
the file. 

9 The file is a disk file and the Release in- 
struction is to be generated for the file. 

The character entered as the operand of the order 
entry becomes the low-order character of the x-control 
field of all the input/output instructions generated 
for the file. These input/output instructions are con- 
tained in the iorw's (Input/Output Request Words) 
that are used to process the file, (iorw's are discussed 
under "Internal Operation of the iocs." ) 

An example of how this entry is coded is shown in 
Figure 51. 
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Figure 51. order Entry 
IOAREAS 

The ioareas entry causes the iocs to generate an In- 
put/Output Request Word (iorw) for each input/ 
output area whose label appears as an operand of the 
entry. The iocs uses the iorw's generated to schedule 
and implement input/output operations on the file. 
If the programmer plans to generate these iorw's, this 
entry is not required. (Input/Output Request Words 
are discussed under "Internal Operation of the iocs.") 

The ioareas entry may have a fourth operand that 
was not covered in the previous discussion of the 
ioareas entry (see Figure 52). The fourth operand 
may be any label that consists of from one to nine 
alphameric characters. The iocs takes this label, adds 
the character A, B, or C, and assigns the modified 
label, respectively, to the first, second (if any), and 
third (if any) iorw generated by the other operands 
of this entry. 

If less than three input/output areas are specified 
by this entry, and labeling of the iorw's that are 



generated is desired, the comma(s) that would nor- 
mally separate the labels entered as the second and/or 
third operands must be included in the entry (see 
Figure 53). 
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Figure 52. ioareas Entry (Four Operands) 
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Figure 53. ioareas Entry (Two Operands Omitted, Labeling 
Desired ) 



ERRCHECK 

In addition to the operands discussed earlier, this 
entry has two other possible operands (see Figure 
55). They are: 

operand explanation 

STORE This operand causes the IOCS to store the 

contents of the E- or F-address register 
(whichever is appropriate) in the Address 
Register Field of the affected IORW after 
execution of the input/output instruction in 
the Input/ Output Operation Field of the 
IORW. ( IORW's are discussed under "In- 
ternal Operation of the IOCS.") 

This operand should not be specified if 
the file consists of variable-length records, 
and the WLR operand has been specified 
for the file. Under these conditions, the 
IOCS places the length of the last record 
read from the file in the Address Register 
Field of the relevant IORW, instead of the 
contents of the E- or F-address register. 
x This operand can be any single character. 

If this operand (hereafter referred to as the 
fourth operand) is included, it must always 
be the last operand of the ERRCHECK 
entry. This operand is used to prevent the 
IOCS from checking, after each input/output 
operation performed on the file, those chan- 
nel status indicators whose associated BCD 
bits are not included in the BCD code of 
the character entered. Extreme caution must 
be expected when using the operand. The 
channel status indicators and their associated 
BCD bits are shown in Figure 54. 

Note: The iocs does not consider the Busy channel 
status indicator (i.e., 2 bit) an error indicator. If this 
indicator is on, the iocs does not indicate that an 
error condition exists on the relevant file. Instead, the 
iocs immediately retries the affected input/output 
operation. 
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Channel Status 
Indicator 


Associated BCD 
Bit 


B 
A 
8 
4 
1 


Wrong-length record 
No Transfer 
Condition 
Data Check 
Not Ready 



Figure 54. Channel Status Indicators and Associated bcd Bits 



If the fourth operand is omitted, the wlr operand 
is included, and the file consists of Form 1 or Form 2 
records, the iocs checks all the channel status indi- 
cators. If this operand and the wlr operand are 
omitted, regardless of the record form used by the 
file, the iocs checks all the channel status indicators 
except the Wrong-Length-Record indicator. 

If the fourth operand is used, its bcd code does not 
include the B bit, and the file consists of Form 1 or 
Form 2 records, the iocs does not interrogate the 
Wrong-Length-Record indicator, even if the wlr 
operand has been specified. If the file consists of Form 
3 or Form 4 records and the wlr operand was speci- 
fied, the iocs makes a program check for wrong-length 
records by confparing the length of the record just 
read or written with the relevant Block Character- 
Count regardless of whether the fourth operand is 
used and whether it contains a B bit. 

If the fourth operand is used and any of the other 
operands are omitted (i.e., wlr, wdc, or store), the 
comma that would normally separate the omitted 
operand from the next succeeding operand must be 
included ( see Figure 56 ) . 
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Figure 55. errcheck Entry (Four Operands) 
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Figure 56. errcheck Entry (Two Operands Omitted; Fourth 
Included. 



ERRADDR 

This entry is not required. It is used to specify the con- 
ditions under which the iocs is to exit to an error 
routine the programmer has provided for the file. 

The erraddr entry may have a minimum of one, and 
a maximum of six operands. The first operand is the 
label of the error routine the programmer has pro- 



vided for the file. (This operand may be omitted. If 
it is, the comma that would normally separate it from 
the next operand must be included in the entry.) 
Each of the second through sixth operands consists 
of a single character. The characters that may appear 
as these operands are shown in Figure 57. 



Filetype 
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Not Ready 
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Data Check 
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Condition (End-of-File) 
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Wrong Length Record 
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Data Check and Wrong Length Record 
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Condition and Wrong Length Record 
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Data Check, Condition, and Wrong Length Record 
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Dqta Check and Condition 
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Not Ready (i.e., 7631 File Control Off-Line) 


9 


Condition (i.e., 1301 Disk Storage Circuit Check, 
Invalid Operation code, or Write Disk Check 
Without Mode setting) 


5 


Data Check (i.e., Parity Check) 


V 


Data Check, NoTransfer (i.e. , Invalid Track Number), or 
Data Check, NoTransfer, and Cond (i.e., Mode Check) 


Z 


No Transfer, Condition (i.e-. , No Record Found, 1301 
Disk Storage Circuit Check, or 7631 File Control 
Circuit Check) 
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Data Check 
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Wrong Length Record, Data Check 
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Condition (i.e., 1301 Disk Storage Circuit Check) 


Q 


Wrong Length Record, Condition (i.e., 1301 Disk 
Storage Circuit Check plus Wrong Length Record) 


A 


No Transfer (Write Inhibit Switch on 7631 is ON) 




Wrong Length Record (i.e., Incorrect Format Length, or 
No GM-WM at End of Disk Control Word) 



Figure 57. Acceptable Characters 

If: (a) the channel status indicator(s) turned on 
by an error condition, or conditions, that occurred on 
the file exactly match the channel status indicator(s) 
indicated by the bcd code of one of the single-char- 
acter operands, and (b) two commas do not appear 
between the first operand and the single-character 
operand (see the second and third operands shown 
in Figure 58), the iocs performs two operations. It 
bypasses its normal error procedures and causes a 
branch to be executed to the user's error routine. (If 
the first operand has been omitted, the iocs bypasses 
its normal error correction procedures, and accepts the 
record. ) 

Note: This is the only type of exit that may be 
specified for files that reference unit-record devices. 

If: (a) the channel status indicator(s) turned on 
by an error condition, or conditions, exactly match the 
channel status indicator(s) indicated by the bcd code 
of one of the single-character operands, and (b) two 
commas do appear between the first operand and that 
single-character operand (see the fourth, fifth, and 
sixth operands shown in Figure 58), the iocs causes 
a branch to be executed to the user's error routine 
only if the normal iocs error procedures have been 
executed, and the condition or conditions could not 
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be corrected. (If the first operand has been omitted, 
no branch is executed and the relevant operands be- 
come redundant. ) 

Any single-character operand of this entry whose 
bcd code includes the B bit, cannot have its intended 
effect, if: (a) the file consists of Form 1 or Form 2 
data records, and (b) neither the wlr operand nor 
a fourth operand whose bcd code includes the B bit 
have been specified in the dtf errcheck entry for the 
file. If the file: (a) consists of Form 3 or Form 4 data 
records, and (b) the wlr operand has been specified 
in the errcheck entry for the file, any single-char- 
acter operand of the dtf erraddr entry whose bcd 
code includes the B bit will have its intended effect, 
even though the bcd code of the fourth operand speci- 
fied in the errcheck entry for the file does not include 
the B bit. 
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Figure 58. erraddr Entry 

Disk Files: A group mark entered as the second or 
sixth operand of the dtf erraddr entry for a disk file 
causes the iocs to exit to the user's error routine if 
any channel status indicator is turned on as the result 
of an input/output operation performed on the file. 

If the group mark is entered as the second operand, 
the normal iocs error procedures are bypassed, and 
any subsequent operands are redundant. (See Figure 
59.) 

If the group mark is entered as the sixth operand, 
the normal iocs error procedures are not bypassed. In 
this case, any operand except the group mark operand 
entered after the double comma entry is superfluous. 
( See Figure 60. ) 

If the group mark appears as the sixth operand and 
the programmer wishes to omit one or more of the 
other operands, a comma must be substituted for each 
missing operand. (See Figure 61.) 
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Figure 59. erraddr Entry ( Second Operand; =^ ) 
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Figure 60. erraddr Entry ( Sixth Operand; ^ ] 
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Figure 61. erraddr Entry (Operands Omitted) 

In Figure 61, the first two commas entered before 
the group mark operand represent the omitted fourth 
and fifth operands. The third and fourth commas are 
the normal double-comma entry. 

LENGTH 

This entry is required if the file consists of Form 4 
data records and the programmer plans to use the 
put file,form4 macro-instruction to write on the file. 
The operand of the length entry is a label the iocs 
assigns to Field 12 of the File Table associated with 
the file. (This label must not be a linkage symbol. 
This label refers to the low-order position of the field. ) 
Whenever the programmer is going to use the put 
file,form4 macro-instruction, he must first place, in 
this field, the estimated maximum length of the data 
record that is to be handled. The manner in which the 
iocs utilizes this information is discussed under put 
file,form4. An example of how this entry is coded is 
shown in Figure 62. ( See "The Extended iocs Macro- 
Instructions" for a discussion of put file,form4 and 
"Internal Operation of the iocs" for a description of 
the File Table. ) 
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Figure 62. length Entry 



INTADDR 



This entry is not required. It is used to cause a branch 
to be taken to a service routine provided for the file 
by the programmer whenever execution of an input/ 
output operation (other than a Seek Disk operation) 
is completed on the file. 

The operand of the intaddr entry is the label of the 
user-written service routine provided for the file. 

If the dtf erraddr and intaddr entries are both 
specified for the same file, the user's service routine is 
not entered if an input/output operation completed 
on the file results in an error condition, or conditions, 
that cause the iocs to exit to the error routine the 
programmer has provided for the file. 

If the skip operand of the dtf erroptns entry and 
the intaddr entry are specified for the same file, the 
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user's service routine is not entered if an input/output 
operation completed on the file results in an error 
condition, or conditions, that the iocs error procedures 
cannot correct. An example of how this entry is writ- 
ten is shown in Figure 63. (User-written service rou- 
tines are discussed under "User- Written Routines.") 
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Figure 63. intaddr Entry 



This entry is not required. It is of significance only if 
the file is a tape file that uses labels. This entry allows 
the programmer to specify up to four exits to tape 
label routines the user has provided for the file. 

There are 16 exits (labeled A-H, J-N, P-R) available. 
These exits are in the iocs tape label routines. The 
position of each of these exits within the various iocs 
label routines is shown in Figure 64 (e.g., Exit A in 
the Input Beginning-of-Reel routine). The system 
symbols that identify the return points from these 
exits are also shown in Figure 64 (e.g., /lra/; the 
return point from Exit A. ) 



Input Beginning 
of Reel Routine 



Input End of 
Reel Routin 



Output Beginning 
of Reel Routine 




Figure 64. iocs Tape Label Routines 
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The exits provided are taken depending on which 
reel of the file the relevant iocs label routine is 
processing. The characters R, F, or B indicate which 
reels of the file are to be affected, as follows: 

CHARACTER REELS AFFECTED 

R All reels of the file except the first, if the 

IOCS tape label routine in which the exit 
is to be taken is an input routine. All reels 
of the file except the last if the affected 
IOCS label routine is an output routine. 

F Only the first reel of the file, if the affected 

IOCS label routine is an input routine. Only 
the last reel, if the affected IOCS label 
routine is an output routine. 

B All reels of the file, regardless of the IOCS 

label routine in which the exit is to be taken. 

Each exit that is to be taken is coded as shown in 
Figure 65. 
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X Y , USERLABEL 



. Label of the user's routine 
-The character R, F, or B 
-The exit label (A-R) . 



Figure 65. Coding Format for Exits to User-Written Label 
Routines (lineI) 



From one to four exits can be specified using this 
entry. The label lineI is entered in the proper field 
of the line of the coding sheet used for this entry and 
the relevant exits are specified on that same line. Each 
exit specified must be separated from the next by a 
comma. An example of how this entry is coded is 
shown in Figure 66. 

line2 

This entry cannot be used unless the lineI entry has 
been specified. This entry allows the programmer to 
specify from one to four additional exits to user- 
written tape label routines. Each exit is coded as 
described under the lineI entry, and must be sepa- 
rated from the next (if any) by a comma. An example 
of how this entry is coded is shown in Figure 67. 

lineI above 

This entry is used to specify exits from the iocs tape 

label routines to tape label routines written for the file 



Figure 67. line2 Entry 

by the programmer when more than eight such exits 
are desired. This entry is not required. 

The lineI above entry cannot be included if the 
lineI entry has been specified for the file. 

The desired exits are specified by providing coding 
of the format shown in Figure 68 for each exit. The 
exits and characters that can be included in this coding 
are the same as those discussed under the dtf lineI 
entry. 
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Figure 68. Coding Format for Exits to User-Written Label 
Routines (lineI above) 



Once the desired exits are specified, the relevant 
coding must be placed before the dtf Header Line 
entry for the file, as shown in Figure 69, and must be 
preceded by a single-character dcw like that shown on 
Line 1 of Figure 69. (This character can be any 
character except a special character such as $.) To 
complete the entry, the exact coding shown on Line 
13 of Figure 69 must be included among the dtf 
entries for the file. 
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Figure 66. lineI Entry 
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EXTEN 

This entry is not required. It applies only to tape files 
that use labels which the iocs is to check. This entry 
can be used to label the File Table Extension gen- 
erated for the file by the dtf label entry. If the dtf 
label entry has been omitted, the exten entry must 
be used to indicate which File Table Extension the 
iocs is to reference while processing the labels of the 
file. (The File Table Extension is discussed under 
"Internal Operation of the iocs.") 

The operand of the exten entry is one of the fol- 
lowing: 

1. For files where the dtf label entry has been 
specified, it is the label assigned to the File Table 
Extension generated by the dtf label entry. 

2. For files where the dtf label entry has been 
omitted, it is the label that has been assigned to a 
File Table Extension the programmer generated, or 
a File Table Extension generated by the dtf label 
entry specified for another file. An example of how 
this entry is coded is shown in Figure 70. 
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Figure 70. exten Entry 



FILELIST 



This entry is used to associate iorw's the programmer 
has generated with a specific data file. The operand of 
the filelist entry is the low-order address of the 
Link Field of an iorw, or the first of a list of iorw's 
the programmer has created. 

The iocs places this address in Field 5 of the ap- 
propriate File Table, if the dtf ioareas entry has not 
been specified for the file. If the dtf ioareas entry has 
been specified, the iocs places this address in the Link 
Field of the last iorw on the File List associated with 
the file. (File Tables and File Lists are discussed 
under "Internal Operation of the iocs.") An example 
of how this entry is coded is shown in Figure 71. 

If the filelist entry is used, the iocs assumes that 



the file uses two or more input/output areas. For this 
reason, if any macro-instructions except get file to 

WORK, PUT WORK TO FILE, Or PUT WORK TO FILE, d are 

issued against the file, the dtf index entry must also 
be included in the dtf statement written for the file. 
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Figure 71. filelist Entry 



User-Written Routines 

Five types of user-written routines can be included 
in programs that incorporate the iocs. The five types 
are end-of-file, error, service, scramble, and label 
routines. End-of-file, error, service and label routines 
are discussed here. Scramble routines are discussed 
under "Disk File Processing." 

Note: The iocs does not store or alter the status 
of the arithmetic overflow or divide overflow indicators 
before entering user-written routines. 

USER-WRITTEN SERVICE ROUTINES 

The ioctl entry macro-instruction must be the first 
instruction of every user-written service routine. The 
second operand of this macro-instruction must be the 
label entered as the operand of the dtf intaddr entry 
specified for the file. The label that appears as the sec- 
ond operand of this macro-instruction refers to the 
low-order position of the coding (see Figure 72) de- 
veloped by the macro-instruction. This coding im- 
mediately precedes the user-written routine. For this 
reason, the first instruction of this routine can be 
referred to by this label -f-1. 

The ioctl exit macro-instruction must be the last 
instruction of every user-written service routine. (The 
ioctl entry and ioctl exit macro-instructions are 
discussed under "The Extended iocs Macro-Instruc- 
tions." ) 

User-written service routines must not issue a get 
or put macro-instruction that results in detection of an 
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Figure 72. Coding Developed by ioctl Entry 
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end-of-reel or end-of-file condition. User-written serv- 
ice routines must not issue ioctl open, close, relse, or 
feor at a time when the iocs may be processing 
an ioctl open, close, relse, or feor encountered 
in the user's main-line program, unless a Tele-Process- 
ing device has been specified for the using installation 
at System Generation by means of the devdf macro- 
instruction. ( See the System Generation publication. ) 
User-written service routines cannot issue a get or 
put against the file with which they are associated, 
unless at least one iorw is on the File List of the file 
at the time the macro-instruction is issued. User- 
written service routines cannot issue a get or put 
against a file other than the one with which they are 
associated if the dtf intaddr entry has been specified 
for the affected file, unless there is at least one iorw 
on the File List of the affected file at the time the get 
or put is issued. In a tp environment, Service routines 
should not use index registers for communication be- 
tween themselves and other Service routines, or them- 
selves and the main line. 

USER- WRITTEN LABEL ROUTINES 

The iocs reads tape labels into and writes tape labels 
out of the areas shown in Figure 73. These areas are 
referred to by the system symbols indicated. 

120-Choracter Label Read/Write Area 



80-Character Read/Write Area 



ALA/ /SLA/ 

Figure 73. Tape Label Read/Write Areas 

Except for ioctl open, close, relse and feor, 
user-written label routines can utilize all the iocs 
macro-instructions, provided their use does not result 
in an end-of-reel or end-of-file condition (i.e., a get 
that causes the final tape mark to be sensed, or a put 
that causes the final reflective strip to be sensed ) . 

Generalized user-written label routines that process 
the labels of more than one file can obtain the 
address of the File Table of the affected file from 
index register 13, or from a five-digit field whose low- 
order address is referred to by the system symbol 
/lfa/. (ab zone bits appear over the units position 
of both index register 13 and the five-position field. ) 

Before returning to the Input End-of-Reel routine be- 
yond Exit E (see Figure 64), user-written label routines 
designed to process nonstandard input trailer labels 
may place either "R" or "F" in a location referred to by 
the system symbol /lef/. The character should be R 
if the programmer wishes the iocs to process the next 
reel of the file; the character should be F if no addi- 
tional reels of the file are to be processed. 



USER- WRITTEN ERROR ROUTINES 

At the time a branch is executed to a user-written 
error routine, the following information is available to 
the programmer: 

1. Index register 13 contains the address of the 
affected File Table, (ab zone bits appear over the 
units position of X13. ) However, the contents of X13 
are destroyed if any iocs macro-instruction is issued 
within the routine or a branch instruction is executed 
to the Resident Monitor. 

2. Field 10 of the affected File Table contains the 
address of the re-entry point into the calling sequence 
generated by the get or put macro-instruction, the 
execution of which uncovered the relevant error con- 
dition. 

3. The affected iorw is at the top of the File List 
with which it is associated. 

4. The Channel Status Character in the affected 
iorw indicates the channel status indicators that were 
turned on by the relevant error condition. 

Once a branch has been executed to a user-written 
error routine, that routine can cause the erroneous 
record: (a) to be processed as if it were error free, 

(b) to be overlaid, if the file is an input file, by 
reading the next logical record from the affected file 
into the input area that contains the erroneous record, 

(c) to be backspaced over, if the file is a tape file, 
and reread into or rewritten out of current input/out- 
put area of the affected file, or (d) to be written on 
the system's Core Image file or another file set up by 
the programmer for this purpose. 

If the erroneous record is to be processed as if it 
were free of error, the user-written error routine must 
cause a branch to be executed to the address contained 
in Field 10 of the affected File Table. 

If the next logical record is to be read into the 
same area that contains the erroneous record, the user's 
routine must change the B bit in the second File 
Indicator (F2) of the affected File Table to an A bit 
by executing the instruction mrzr ,filename+12, 
and cause a branch to be taken to the address in Field 
10 of the affected File Table. 

If the erroneous record is to be reread or rewritten, 
a unctl file,bsp macro-instruction must be issued 
against the relevant file, the block counter (Field 2) 
in the affected File Table must be decremented by 
one, and the steps outlined in the preceding para- 
graph must be executed. 

If the erroneous record is to be written on the Core 
Image file, the programmer must have coded a dtf 
statement for that file, included mdm as the second op- 
erand of the relevant dtf symunit entry, included the 
dtf mode entry with its odd operand, and opened the 
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file by means of the ioctl open,output macro-instruc- 
tion. The user's routine must then place the B-address 
of the input/output operation that appears in the 
affected iorw in the iorw associated with the Core 
Image file, and issue a put macro-instruction against 
the Core Image file. 

This action causes the erroneous record to be written 
on the; Core Image file. The erroneous record may 
then be processed or overlaid as described in the 
preceding paragraphs. 

If the erroneous record is to be written on a file set 
up by the programmer for this purpose, the procedures 
outlined for writing the erroneous record on the Core 
Image file must be followed, with one exception. The 
second operand of the relevant dtf symunit entry 
cannot be mdm, 

Note 1: If a file consists of Form 4 records and the 
error routine provided for the file determines that a 
block of records on which an error condition exists is 
to be processed as if it were error free, the program- 
mer must make sure that the Record Character-Count 
in each record of the block is accurate. 

Note 2: User error routines provided for an output 
file cannot issue ioctl open, close, feor, or relse. 

USER- WRITTEN END-OF-FILE ROUTINES 

Once the end-of-file routine provided for a file has 
been entered, no further get or put macro-instructions 
can be issued against the affected file, unless the file 
is closed and then reopened. The work files discussed 
in Appendix E are an example of the type of files on 
which this situation might frequently occur. 

When an end-of-file condition occurs on a disk out- 
put file, the iocs removes all iorw's associated with 
the file from the Read/Write List and places them on 
the bottom of the File List associated with the file. 
The iocs next causes a branch to be taken to the end- 
of-file routine the user has provided for the file. The 
programmer cannot then use the ioctl close, output 
macro-instruction to write on the file any data re- 
maining in the output areas associated with the file. 
The reasons for this are: (a) the file cannot accept 
any additional data, and (b) the iorw's that refer to 
the relevant output areas are on the File List of the 
file. The programmer must himself determine where 
and how any data contained in these output areas is 
to be disposed of. 



Extended IOCS Macro-Instructions 

The extended iocs macro-instructions are listed below, 

and discussed in the paragraphs that follow. 

GET FILE,DEFER IOCTL CHKPT 

PUT FILE,DEFER IOCTL TYPE,AREA 



PUT FILE,FORM4 
PUT FILE,d 
PUT WORK TO FILE,d 
PUT FILE TO FILE,d 
IOCTL RELSE, (I/O), FILE 
IOCTL FEOR, (I/O), FILE 
IOCTL ENTRY 
IOCTL EXIT 



IOCTL TYPE,AREA,DEFER 
UNCTL FILE,CC,d 
UNCTL FILE,SSF,d 
UNCTL FILE,BSP 
UNCTL FILE,RWD 
UNCTL FILE,RWU 
UNCTL FILE,WTM 



GET FILE,DEFER 

This macro-instruction is designed for use with input 
files that consist of unblocked records and use a single 
input area. It allows the programmer to overlap read 
operations and processing when only one input area 
has been assigned to the file. This macro-instruction 
causes the iocs to schedule execution of an input 
operation that is to read a record from the indicated 
file, (e.g., the file labeled infile in Figure 74) into 
the input area specified for the file. This macro- 
instruction then causes the iocs to branch to the next 
sequential instruction of the using program without 
waiting for execution of the requested input operation 
and subsequent release of the input area to the using 
program (i.e., the iocs defers making the requested 
record available in the input area of the file. ) 

Once get file,defer has been issued, the using pro- 
gram can process any data except data contained in 
the input area. When the program has completed 
whatever processing is required, get file; get file to 
work; or get file to file can be issued. These macro- 
instructions cause the iocs to make the record read 
as a result of issuing get file,defer available to the 
user's program. 

If the programmer wishes, instead of get file; get 
file to work; or get file to file, the character in 
Field Q4 of the affected iorw can be tested to deter- 
mine if the relevant input area is available. If the bcd 
code of the character in Field Q4 includes the A bit, 
the requested input operation has been completed and 
the associated area is available. If the programmer 
substitutes a B bit for the A bit, he may access the 
contents of the input area. If the bcd code includes the 
B bit, the requested operation has not been completed 
and the programmer can: (a) process other data, (b) 
wait until the iocs replaces the B bit with an A bit, or 
(c) issue one of the get macro-instructions noted 
above, to effect completion of the operation. 

If get file,defer is used, the iocs suppresses the 
check for end of file that the other get macro-instruc- 
tions cause it to make. However, the use of get file, 
get file to work, or get file to file, subsequent to 
the use of get file,defer causes the iocs to recognize 
an end-of-file condition that results from the issuance 
of get file,defer. An example of how this macro- 
instruction is coded is shown in Figure 74. 
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Figure 74. get file,defer 
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Figure 75. put file,defer 



PUT FlLE,DEFER 

This macro-instruction is designed for output files that 
consist of unblocked records and use a single output 
area. It allows the programmer to overlap write op- 
erations and processing when only one output area 
has been assigned to the file, put file,defer causes 
the iocs to schedule execution of an output operation 
that is to write, on the affected file (e.g., the file 
labeled outfile in Figure 75), a record taken from 
the output area specified for the file. This macro- 
instruction then causes the iocs to branch to the next 
sequential instruction of the user's program, without 
waiting for actual execution of the requested write 
operation and release of the output area to the pro- 
gram (i.e., the iocs defers making the output area 
available to the using program ) . 

Once put file,defer has been issued, the using pro- 
gram can process any data except that data contained 
in the output area of the file. When the program has 
finished processing the relevant data, put file can be 
issued. This macro-instruction causes the iocs to en- 
sure that the write operation scheduled by put 
file,defer has been executed. The iocs then makes 
the output area of the file available to the program. 

If the programmer wishes, instead of issuing put 
file the character in Field Q4 of the affected iorw 
can be tested to determine if the relevant output area 
is available. If the bcd code of the character in Field 
Q4 includes the A bit, the requested write operation 
has been executed, and the output area associated 
with the file is available to the using program. If the 
programmer substitutes a B bit for the A bit, he may 
access the output area. 

If the bcd code of the character includes the B bit, 
the requested operation has not completed and the 
programmer can: (a) process other data, (b) wait 
until the iocs replaces the B bit with an A bit, or (c) 
issue a put macro-instruction against the file to effect 
the completion of the requested write operation. 

If put file,defer is used, the iocs suppresses the 
check for end of file which other put macro-instruc- 
tions cause it to make. However, the subsequent use 

of PUT FILE; PUT WORK TO FILE; Or PUT FILE TO FILE 

causes any end-of-file condition that resulted from 
use of put file,defer to be recognized by the iocs. An 
example of the way in which this put macro-instruc- 
tion is coded is shown in Figure 75. 



PUT FILE,FORM4 

This macro-instruction is only used when the affected 
file (e.g., the file labeled outfile in Figure 76) con- 
sists of Form 4 records and the programmer plans to 
move the next logical record into the current output 
area of that file by means of a move instruction, rather 
than by means of an iocs macro-instruction. 

put file,form4 is used as follows: 

1. The programmer places the actual length, or the 
maximum possible length, of the record that is to be 
moved in a five-digit field whose label is the operand 
of the dtf length entry specified for the file. This 
placement should be accomplished by means of a 
Zero and Add instruction (za). 

2. The programmer issues put file,form4. This 
macro-instruction causes the iocs to check the current 
output area of the file. ( In performing this check, the 
iocs destroys the contents of the five-digit field that 
is referred to by the label entered as the operand of 
the length entry. ) 

If the current area does not contain enough positions 
unoccupied by data to absorb the record, the current 
contents of the area are written on the file and the 
iocs branches to the next sequential instruction of the 
program. 

If the current area contains enough positions to 
absorb the record, the iocs branches to the next 
sequential instruction of the program. 

3. The programmer moves the next logical record 
into the current output area by means of a move 
instruction that wipes out any extraneous word marks 
in that portion of the current output area that is 
taken up by the next logical record. 

4. The programmer issues put file. This macro- 
instruction causes the iocs to account for the record 
the programmer moved into the output area and to 
branch to the next sequential instruction of the pro- 
gram. An example of how this put macro-instruction 
is coded is shown in Figure 76. 
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Figure 76. put file,form4 
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PUT FILE,d PUT WORK TO FILE,d PUT FILE TO FILE,d 

These macro-instructions may only be used with 
punched card or printer files. They perform, respec- 
tively, the same functions as put file, put work to 

FILE and PUT FILE TO FILE. 

In addition, these macro-instructions: 

1. For punch files, allow the programmer to alter 
the stacker assigned to the file during execution of 
the user's program. (This is accomplished by substi- 
tuting 0, 4, or 8 for the d-character shown in Figure 
77.) 

2. For printer files, allow the programmer to specify, 
during execution of the program, whether the Write 
A Line or the Write Word Marks instruction is to be 
used to write on the file. This is acomplished by sub- 
stituting (i.e., Write A Line) or 1 (i.e., Write Word 
Marks ) for the d-character shown in Figure 77. 

The last put FiLE,d; put work to FiLE,d; or put 
file to FiLE,d encountered during execution of the 
using program establishes the stacker or print in- 
struction that is to be used for the balance of the 
program, provided the file uses a single output area. 
If the file uses multiple output areas, the program- 
mer must issue put FiLE,d; put work to FiLE,d; or 
put file to FiLE,d for the balance of the program 
whenever he issues a put macro-instruction against 
the affected file. 

If none of these macro-instructions are used in the 
program, the stacker or instruction specified in the 
dtf order entry for the file is the stacker or instruction 
used throughout the program. An example of how 
these macro-instructions are coded is shown in Figure 
77. 



Line 

3 5 


Label 
6 15 


Operation 

16 20 


21 25 30 35 40 


0, 1, 


AMV.lAd&L, . 


PUT . 


OU.T,EI.L,£ r d 


2 


H.ti,Y,LA&e.U , 


PUT. . 


work jo ootf, i ,<,,£, ,d, , . . 


0,3. 


A.NY.L,A3\t.L. . 


PUT. , 


i.HF.i.L.e. to. aorrA.ue.. 4. ,.l 



Figure 77. put file,c1; put work to itle,c1; and put file to 

FILE,d 
IOCTL RELSE, ( INPUT/OUTPUT ) ,FILE 

This macro-instruction may only be used with files 
that consist of Form 2 or Form 4 data records. This 
macro-instruction causes the iocs to make the current 
block of data records from the relevant file unavailable 
to the user's program. The first operand of this macro- 
instruction is relse (Release), the second operand is 
input (for input files), or output (for output files); 
the third operand is the name of the affected file. 

If the second operand is input, the iocs ignores 
any records in the current input area that have not 
been made available to the program, and the next 
get macro-instruction issued against the file causes 



the iocs to make the first record of the next logical 
block of records available to the program. 

If the second operand of this macro-instruction is 
output, the iocs: (a) ignores the fact that the block 
of records in the current output area of the file is in- 
complete, (b) pads the incomplete block if the file 
consists of Form 2 records, and (c) schedules the 
writing of the block on the appropriate file. The next 
logical record moved into the output area then be- 
comes the first record of a new block. An example of 
how this macro-instruction is written is shown in Fig- 
ure 78. 
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Figure 78. ioctl relse, ( input/output ) ,file 



IOCTL FEOR, ( INPUT/OUTPUT ) ,FILE 

This macro-instruction is issued against tape files to 
force an end-of-reel condition. The first operand of this 
macro-instruction is feor (Force End of Reel). The 
second operand is input (for input files) or output 
(for output files). The third operand is the label of 
the affected file. 

If the second operand is input, a branch is im- 
mediately taken to the iocs Input End-of-Reel rou- 
tine. As a result, the trailer label of the affected reel 
is not processed, and no check is made to determine 
if an end-of-file condition exists on the file. 

If the second operand of this macro-instruction is 
output, the iocs: (a) completes all output operations 
issued against the file that are still pending, (b) pads 
the last block of data records if the file consists of 
Form 2 records and the last block is incomplete, (c) 
writes on the file all records (or blocks of records) 
in the output area(s) of the file, and (d) branches 
to the appropriate iocs Output End-of-Reel routine. 
An example of how this macro-instruction is written 
is shown in Figure 79. 
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Figure 79. ioctl feor, ( input/output ) ,file 



IOCTL ENTRY 

The ioctl entry macro-instruction must be the first 
instruction of every user-written service routine. It 
is used to define the entry point into the user-written 
service routine whose label appears as its second 
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operand. Figure 80 shows an example of how this 
macro-instruction is written. (The coding generated 
by this macro-instruction is shown in Figure 72. ) 
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Figure 80. ioctl entry 

IOCTL EXIT,ACCEPT IOCTL EXIT,DELETE 

One of these macro-instructions must appear as the 
last instruction of every user-written service routine 
( see Figures 81 and 82 ) . ioctl exit,accept causes the 
iocs to accept the results of the input/output opera- 
tion, the completion of which initiated entry into the 
affected user-written service routine, ioctl exit,delete 
causes the iocs to note that the iorw associated with 
the input/output operation, the completion of which 
initiated entry into the affected user-written routine, 
has been deleted from the group of iorw's (i.e., the 
Service List) associated with the routine. The iocs 
assumes the user has disposed of the iorw. (Service 
Lists are described under "Internal Operation of the 

IOCS. ) 
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Figure 81. ioctl exit, accept 
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Figure 82. ioctl exit.delete 
IOCTL CHKPT 

This macro-instruction causes the iocs to write three 
records on the Core Image file. The first of these 
records includes the entire contents of core storage. 
The second includes the contents of core storage from 
the last position occupied by the Resident Monitor -f-1 
to the end of core storage. The third includes the 
contents of core storage from the address specified 
as the tenth operand of the iokdf macro-instruction 
to the end of core storage. ( See the System Generation 
publication.) This address is automatically stored in 
a five-position field whose low-order position may be 
referred to by the system symbol /org/. 

Once this macro-instruction has been executed a 
message is written on the console printer notifying the 
operator that a checkpoint is being taken. 



The use of this macro-instruction allows the program 
to be restarted at the point in the program where the 
ioctl chkpt macro-instruction was issued. For a de- 
scription of the procedure for restarting programs 
from a checkpoint see the publication, IBM 1410/7010 
Operating System; Operator's Guide, Form C28-0351. 

Programs that use the ioctl chkpt macro-instruc- 
tion must observe the following conventions: 

1. Each time a tape is backspaced by means of the 
unctl file,bsp macro-instruction, the block counter 
(Field 2 of the File Table) of the affected file must 
be decremented by one. 

2. If any reel of a tape file has been rewound by 
means of the unctlfile,rwd or unctlfile,rwu macro- 
instruction since the last time the file was opened, 
that file must be closed before the ioctl chkpt macro- 
instruction is executed if the file uses labels. If the file 
does not use labels, it need not be closed, but Field 2 
of the relevant File Table must be zeroed before the 
macro-instruction is executed. 

3. The ioctl chkpt macro-instruction cannot be 
used if a file is open for which N has been specified 
in the operand field of the dtf rwdoptns entry, and 
the condition specified by the operand field in which 
it appears (e. g., beginning of reel, end of reel, etc.) 
has occurred. 

4. If two or more files use the same tape unit, only 
one of these files can be open at the time the ioctl 
chkpt macro-instruction is executed. 

5. If one or more iorw's have been added to the 
File List associated with a tape file after the file is 
opened, and the new iorw's reference a different tape 
unit than the iorw's that were on the File List at the 
time the file was opened, the file must be closed be- 
fore the ioctl chkpt macro-instruction is executed. 

If the iorw's on the File List of a tape file have been 
altered, since the file was opened, to reference a tape 
unit other than the unit they were assigned to at the 
time the file was opened, the affected file must be 
closed before the ioctl chkpt macro-instruction is 
executed. 

6. Files which use 1410 80-character or ibm Stand- 
ard 120-Character labels cannot be open at the time 
the ioctl chkpt macro-instruction is executed if the 
File Table Extension address or the contents of the 
File Table Extension used by the files have been mod- 
ified since the file was opened. 

7. Any file that uses nonstandard labels cannot be 
open at the time the ioctl chkpt macro-instruction is 
executed, if the exits provided in the iocs tape label 
routines are used by the programmer to bypass iocs 
reading or writing of the labels used by the file. 

8. Word separator characters with word marks can- 
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not be present in that area of core storage occupied by 
the using program at the time the ioctl chkpt macro- 
instruction is executed. 

9. Checkpoints cannot be taken at a point in the 
user's program that will require the restart program 
to position a reel of tape mounted on a 7330 magnetic 
tape unit at a record that is longer than the algebraic 
difference between the integers at /ogr/ and /org/. 

After an ioctl chkpt macro-instruction has been 
executed, a three-position field (whose units position 
can be referred to by the system symbol /cpt/) con- 
tains the serial number (hundreds and tens positions 
of the field) of the checkpoint that was just written. 
The units position of this field contains an indicator 
that the using program can interrogate to determine 
if the program has been restarted from the last check- 
point taken. This indicator is the character R if the 
program has been restarted. In this case, the hundreds 
and tens positions indicate the serial number of the 
checkpoint from which the program was restarted. An 
example of how this entry is coded is shown in Fig- 
ure 83. 
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Figure 83. ioctl chkpt 
IOCTL TYPE,AREA 

This macro-instruction is used to cause the iocs to 
write the contents of a specified area of core storage 
on the console printer. This action is taken before the 
next sequential instruction of the using program is 
executed. The first operand of this macro-instruction is 
type. The second operand is any label that refers to 
the high-order position of the area whose contents are 
to be written on the console printer. A group mark 
with word mark must appear immediately to the right 
of the low-order position of this area. Figure 84 shows 
an example of how this macro-instruction is coded. 



out waiting for execution of the scheduled write oper- 
ation. The first operand of this macro-instruction is 
type. The second operand is any label that refers to 
the high-order position of the area whose contents are 
to be written on the console printer. (A group mark 
with word mark must appear immediately to the right 
of the low-order position of this area.) The third 
operand is defer. An example of how this macro-in- 
struction is written is shown in Figure 85. 
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Figure 85. ioctl type, area, defer 

UNCTL Macro-Instruction 

There are six unctl macro-instructions. They may be 
used to generate the coding required to perform cer- 
tain control functions on the input/output unit as- 
signed to a file. These macro-instructions are discussed 
in the paragraphs that follow. The control functions 
they perform are discussed in detail in the publication, 
IBM 1410 Principles of Operation, Form A22-0526. 

Note: The first operand of every unctl macro-in- 
struction is the name of the affected file. The program- 
mer may substitute for the name of the file, the system 
symbol entered as the second operand of the dtf 
symunit entry specified for the file. If this substitution 
is made, the relevant system symbol must be preceded 
and followed by a slash (e.g., /mr9/). (When this 
symbol is entered in the dtf symunit entry, it may or 
may not be preceded and followed by slashes. ) 

UNCTL FILE, CC, d 

This macro-instruction ( see Figure 86 ) corresponds to 
the cc (Control Carriage) mnemonic instruction for 
the 1403 Printer. The first operand is the label of the 
file to which the printer is assigned. The second oper- 
and is cc. The third operand is the d-character of the 
Control Carriage instruction. 



Line 



Label 



Operation 
" 22 



A MYLAAk.L. 



2J_ 



JLQCXi 



_2S_ 



_2P_ 



_4fi_ 



T*P.E. I .M.S.S.A.R.EA 



Figure 84. ioctl type,area 
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Figure 86. unctl file, cc,d 



IOCTL TYPE,AREA,DEFER 

This macro-instruction causes the iocs to schedule the 
writing of the contents of a specified area of core stor- 
age on the console printer. The iocs then executes the 
next sequential instruction of the using program with- 



UNCTL FILE, SSF, d 

This macro-instruction ( see Figure 87 ) corresponds to 
the ssf (Select Stacker and Feed) mnemonic instruc- 
tion for the 1402 Card Read Punch. The first operand 
is the name of the file to which the card reader is as- 
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signed; the second operand is ssf; the third operand 
is the d-character of the Select Stacker and Feed in- 
struction. (If this macro-instruction is used, the dtf 
statement for the affected file must include the dtf 
order entry with 9 as its operand. ) 
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Figure 87. unctl file, ssf, d 



UNCTL FILE,BSP 

This macro-instruction ( Figure 88 ) corresponds to the 
bsp (Backspace) mnemonic instruction for ibm mag- 
netic tape units. The first operand is the name of the 
file to which the tape unit is assigned. The second op- 
erand is the Backspace mnemonic instruction. 
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Figure 88. unctl file, bsp 



UNCTL FILE, RWD 

This macro-instruction (Figure 89) corresponds to the 
rwd (Rewind) mnemonic instruction for ibm mag- 
netic tape units. The first operand is the name of the 
file to which the tape unit is assigned. The second op- 
erand is the Rewind mnemonic instruction. 
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Figure 89. unctl file, rwd 



UNCTL FILE,RWU 

This macro-instruction (Figure 90) corresponds to the 
rwu (Rewind and Unload) mnemonic instruction for 
ibm magnetic tape units. The first operand is the name 
of the file to which the tape unit is assigned. The sec- 
ond operand is the Rewind and Unload mnemonic in- 
struction. 
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UNCTL FILE,WTM 

This macro-instruction ( Figure 91 ) corresponds to the 
wtm (Write Tape Mark) mnemonic instruction for 
ibm magnetic tape units. The first operand is the name 
of the file to which the unit is assigned. The second 
operand is the Write Tape Mark mnemonic in- 
struction. 
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Figure 90. unctl file,rwu 



Figure 91. unctl file, wtm 

Disk File Processing 

This section provides the information required to use 
the iocs to process disk files. 

Disk Files 

A disk file is a data file which the iocs is to read from 
or write in 1301 Disk Storage. The first operand of the 
dtf symunit entry for a disk file must be 1301, and 
the operand of the dtf order entry must specify the 
disk input/output instruction that is to be used to 
process the file. 

Programs that incorporate the iocs may only read 
from or write on those disk files contained in modules 
of 1301 Disk Storage that have been specified, at Sys- 
tem Generation, by means of the dskdf macro-in- 
struction. 

The skip operand of the dtf erroptns entry may not 
be specified for any nonsequential disk file. The dtf 
eofaddr entry must be specified for all sequential disk 
files. (The various sequential and nonsequential disk 
files are discussed in the material that follows. ) 

Note: The operand of the DTF FILEFORM entry 
for nonsequential disk files must be 1 or 3. 

FORM A 

A Form A (Sequential-Full Track) disk file is a disk file 
organized in such a way: (a) that it is to be read or 
written by means of the Read/Write Full Track With- 
out Record Addresses, the Read/Write Full Track 
With Home Address, or the Read/Write Full Track 
With Addresses instruction, and (b) the iocs is to in- 
crement the current track address by one to obtain the 
address of the next track to be read or written. 

When the current track address of a Form A disk 
file has been incremented to the point where it is one 
higher than the address of the last track contained in 
the current physical unit assigned to the file, the iocs 
determines: (a) whether an alternate physical unit is 
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to be assigned to the file, or (b) whether an end-of-file 
condition exists on the file. If an alternate unit is to be 
assigned, the iocs links with the System Monitor to 
effect the assignment and then passes control to the 
user's program. If an end-of-file condition exists on the 
file, the iocs causes a branch to be executed to the 
user's end-of-file routine for the file. 

Input/output areas associated with Form A disk files 
must conform to the format shown in Figure 92. 



Track Address Field 



A M TTTT HA =j= 



T- 



DATA 



HA22 



Current Track 
orCylinder Address 

Mo'du I e 



•IOCS Update 



-Access Mechanism 
B-Address of Input/Output Instructions Referencing This Area 

Figure 92. Input/Output Areas ( Form A and B Disk Files ) 

The iocs supplies the information contained in the 
Track Address Field shown in Figure 92. The iocs up- 
dates the current track address at the low-order po- 
sition of the subfield shown at tttt. 

form b 

A Form B (Nonsequential-Full Track/Cylinder) disk 
file is a disk file organized in such a way: (a) that it is 
to be read or written by means of one of the Full 
Track instructions or by means of the Read/Write 
Cylinder Operation instruction, and (b) the iocs can- 
not increment the current track address by one to 
obtain the address of the next track that is to be read 
or written. 

Note: Form B disk files are the only disk files that 
may be read or written by means of the Read/Write 
Cylinder Operation instruction. 

For Form B disk files, the iocs makes no check to 
determine if an end-of -physical-unit or end-of-file con- 
dition has occurred on the file. 

Input/output areas associated with Form B disk files 
must conform to the format shown in Figure 92. 

For this type of disk file, the programmer must sup- 
ply the information contained in the Track Address 
Field. 

To read records from or write records on Form B 
disk files, the programmer must perform the following 
operations: 

1. Place the address of the next disk track the iocs 



is to read or write in the appropriate portion of the 
Track Address Field associated with the input/output 
area that is to handle the affected records. 

2. Make sure that the B-address of the input/out- 
put instruction in the iorw at the top of the File List 
associated with the affected file refers to the appropri- 
ate input/output area. 

3. Issue the nonsequential form of the desired get 
or put macro-instruction. (See "Disk Macro-Instruc- 
tions.") iorw's, File Lists, and File Tables are dis- 
cussed under "Internal Operation of the iocs." 

Single-Record Disk Files 

A single-record disk file is a disk file the iocs is to read 
or write by means of the Read/Write Single Record 
instruction. There are five types of single-record disk 
files. Each of these five types is discussed in the ma- 
terial that follows. 

FORMC 

A Form C (Sequential-Geometric) disk file is a single- 
record disk file organized in such a way that: (a) the 
iocs can increment the current record address by one 
to obtain the address of the next record that is to be 
read or written, ( b ) the first four digits of the address 
of each record of the file are identical to the first four 
digits of the address of the disk track on which the 
record resides, and ( c ) each track of the file contains 
the same number of data records. 

The dtf fileform entry for this type of file must in- 
clude a second operand. This second operand is an in- 
teger equal to the number of data records contained 
on any one track of the file. An example of a fileform 
entry that includes this operand is shown in Figure 93. 
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Figure 93. fileform Entry ( Second Operand Included ) 

Input/output areas associated with Form C disk files 
must conform to the format shown in Figure 94. 

The iocs supplies the information contained in the 
Track/Record Address Field shown in Figure 94. 

When the, number of data records read from or writ- 
ten on a disk track of this type of file equals the integer 
specified as the second operand of the dtf fileform 
entry for the file, the iocs: resets the subfield yy 
shown in Figure 94 to zeros (00), and increments the 
subfield xxxx by one. 

If the current track address of a Form C disk file 
has been incremented to the point where it is one 
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Track/Record Address Field 
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Figure 94. Input/Output Areas ( Form C Disk Files ) 



higher than the last track of the current physical unit 
of the file, the iocs performs the same functions de- 
scribed under "Form A." 

FORMD 

A Form D (Nonsequential-Geometric) disk file is a 
single-record disk file organized in such a way that: 
(a) the iocs cannot increment the current record ad- 
dress by one to obtain the address of the next record 
to be read or written, and (b) the first four digits of 
the address of each record contained in the file are 
identical to the first four digits of the address of the 
disk track on which the record resides. 

Input/output areas associated with Form D disk 
files must conform to the format shown in Figure 95. 



Track/Record Address Field 



A M XXXX YY 



Current 

Track 

Address 



DATA 



B-Address of Input/Output 
Instructions Referencing 
This Area 



Current Record Address 
•Module 
■Access Mechanism 



Figure 95. Input/Output Areas ( Form D Disk Files ) 



address of the next logical data record in subfield 
amxxxx shown in Figure 95, and place the two digits 
that make this track address the record address of the 
next logical data record in subfield yy. (The iocs uses 
amxxxx to issue the necessary Seek Disk instruction. 
It uses amxxxxyy to execute the desired read or write 
operation. ) 

2. Make sure that the B-address of the input/out- 
put instruction in the top iorw on the File List associ- 
ated with the affected file refers to the appropriate in- 
put/output area. (Input/Output Request Words are 
discussed under "Internal Use of the iocs.") 

3. Issue the nonsequential form of the desired get 
or put macro-instruction (e. g., put file,nseq). See 
"Disk Macro-Instructions" for a discussion of non- 
sequential macro-instructions. 

The iocs cannot check for end-of-physical-unit or 
end-of-file conditions on this type of file. 

FORM E 

A Form E (Sequential-Nongeometric) disk file is a 
single-record disk file organized in such a way that: 
(a) the iocs can increment the current track address 
by one to obtain the address of the next track from 
which data records are to be read or written, (b) the 
first four digits of the address of each record of the 
file are not identical to the first four digits of the ad- 
dress of the disk track on which the record resides, 
and ( c ) each track of the file contains the same num- 
ber of data records. 

The second operand of the dtf fileform entry must 
be included for this type of file. This operand is dis- 
cussed under "Form C." 

The dtf fileform entry for this type of file must 
also include a third operand. The required third oper- 
and is ngeom. An example of how this entry is coded, 
including this third operand, is shown in Figure 96. 
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Figure 96. fileform Entry ( Second and Third Operands 
Included ) 



The programmer must supply the information 
shown in the Track/Record Address Field illustrated 
in Figure 95. 

In order to read records from or write records on 
Form D disk files, the programmer must perform the 
following operations: 

1. Place the access mechanism, module and track 



The dtf scramble entry must be included in the 
dtf statement for this type of file. The operand of the 
scramble entry is the label of a user-written routine 
(i.e., scramble routine) that provides the iocs with 
the address of the next data record that is to be read 
from or written on the file. An example of how this 
entry is coded is shown in Figure 97. 

When a request for a read or write operation against 
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a Form E disk file is noted, the iocs performs the fol- 
lowing operations: 

1. Places the B-address of the requested input/out- 
put o Deration in index register 15. 

2. Moves the current track address (updated if 
necessary) into both the affected Track Address Field 
and Record Address Field (Figure 98). (The iocs 
follows the updating procedure outlined under "Form 
C" for this type of file. ) 

3. Causes a branch to be taken to the scramble 
routine provided for the file. 

The user's scramble routine must then: (a) compute 
the address of the proper data record, (b) place this 
address in the relevant portion of the affected Record 
Address Field (see Figure 98), and (c) cause a branch 
to be taken back to the iocs at /scr/. 

Note: The user's scramble routine can neither make 
use of iocs macro-instructions nor cause the using 
program to enter Priority Alert. (The using program 
is removed from Priority Alert when the iocs passes 
control to the user's scramble routine. ) 



Line 



Label 



Operation 
!S iS. 



o,i, S.CR.AM&L.E 



£J_ 



_S5_ 



_22_ 



-2£_ 



-jUL 



SCR.AMROOT. . . . 



Figure 97. scramble Entry 

Input/output areas associated with Form E disk 
files must conform to the format shown in Figure 98. 

Track Address Field Record Address Field 
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Figure 98. Input/Output Areas ( Form E Disk Files ) 

The iocs supplies the information contained in the 
Track Address Field and Record Address Field shown 
in Figure 98, with one exception. The programmer 
must provide the information contained in the current 
record address portion of the Record Address Field. 

When the current track address of this type of file 
has been incremented to the point where it is one 



higher than the address of the last track of the physi- 
cal unit currently assigned to the file, the iocs per- 
forms the same operations it performs for Form A 
disk files in this situation. 

FORM F 

A Form F disk file ( nonsequential — nongeometric ) 
is a single-record disk file organized in such a way 
that: (a) the iocs cannot increment the track address 
by one to obtain the address of the next track from 
which records are to be read or written, and (b) the 
first four digits of the address of each record of the 
file are not identical to the first four digits of the ad- 
dress of the disk track on which the record resides. 

The dtf fileform entry for this type of file must 
include the third operand discussed under "Form E." 
The second operand of the fileform entry discussed 
under "Form C" is not applicable and must be omitted. 
However, the comma that would normally separate the 
second operand from the third operand must be in- 
cluded. An example of how the fileform entry is 
coded, if the third operand is included and the second 
is omitted, is shown in Figure 99. 
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Figure 99. fileform Entry (Second Operand Omitted; Third 
Operand Included) 



Input/output areas associated with this type of file 
must conform to the format shown in Figure 100. 

Track Address Field Record Address Field 



A M TTTT bb $ 



A M RRRRRR 



Leave 
Blank 



Current 

Track 

Address 



Module 
•-Access Mechanism 



DATA 



Current 
Record 
Address 



Module 
■Access Mechanism 



B-Address of Input/Output Instructions 
Referencing This Area 



Figure 100. Input/Output Areas (Form F Disk Files) 

The programmer must supply all the information 
contained in the Track Address Field and Record 
Address Field, shown in Figure 100. 

To read data records from or write data records on 
Form F disk file, the programmer must perform the 
operations described under "Form D." 
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The iocs makes no check to determine if an end-of- 
physical-unit or end-of-file condition has occurred on 
this type of file. 

FORM G 

A Form G (Partitioned Sequential-Geometric) disk 
file is a single-record disk file organized in such a way 
that: (a) the iocs is to read or write only one data 
record per disk track, (b) the record that is to be 
read or written occupies the same relative position on 
each track (e.g., every record of the file is the second 
record on the track that contains it), and (c) the 
iocs is to increment the current track address by one 
to obtain the address of the next record that is to be 
read or written, and the address of the track on which 
that record resides. 

The programmer specifies that a file is a Form G 
disk file by entering 1 as the operand of the dtf order 
entry for the file, and by omitting the second and third 
operands of the dtf fileform entry for the file. 

Input/output areas associated with this type of file 
must conform to the format shown in Figure 101. 

Track/Record Address Field 
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All the information shown in the Track/Record 
Address Field in Figure 101 is supplied by the iocs. 

When the current track address of this type of disk 
file has been incremented to the point where it is one 
higher than the last track of the physical unit current- 
ly assigned to the file, the iocs performs the same 
operations it performs in this situation for Form A 
disk files. See the discussion of "Form A." 
Single-Record Disk File Summary: A summary of the 
characteristics of the various types of single-record 
disk files is shown in Figure 102. 

Note: The iocs cannot process Form C,D,E, and 
F disk files unless the operand 7 appears in the seventh 
operand field of the iokdf macro-instruction at System 
Generation. No such restriction applies to Form A,B, 
or G disk files. 



Disk Macro-Instructions 

All get and put macro-instructions, except put FiLE,d; 
put work to FiLE,d; and put file to FiLE,d, can be 
issued against disk files. However, get and put macro- 
instructions issued against Form B, D, or F disk files 
must include an additional operand. This operand is 
nseq. It must be separated from the preceding operand 
by a comma. An example of how the nseq operand 
is included is shown in Figure 103. 
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Figure 101. Input/Output Areas (Form G Disk Files) 



Figure 103. get infile,nseq (Nonsequential Disk) 
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Figure 102. Single-Record Disk File Summary 
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Internal Operation of the IOCS 



This section provides descriptions of certain aspects 
of the internal operation of the iocs. The following 
topics are discussed: Input/Output Request Word 
(iorw), System Monitor, File Taible, iocs Lists, and 
iocs Error Procedures. 



Input/Output Request Word (IORW) 

The iorw is a group of contiguous fields normally 
generated by the iocs. ( See Figure 104. ) These fields 
contain the information needed to define a specific 
input/output operation, and the status of that opera- 
tion at any given point during execution of the user's 
program. This information is normally provided by the 
iocs, by dtf entries, and by the System Monitor. 

LINK FIELD 

This is a five-position field that links together all the 
iorw's that appear on the same iocs List. It contains 
the address of the low-order position of the Link Field 
of the next iorw on the same list. The Link Field of 
the last iorw on a given list contains 00000. 

FILE LIST ADDRESS FIELD 

This is a five-position field that associates each iorw 
with the File Table of a particular file. It contains the 
address of the low-order position of the File List 
Origin (i.e., Field 5 of the relevant File Table). This 
address may be referred to by the name of the file 
(i.e., the label specified in the operand of the dtf 
Header Line entry for the file ) . 

input/output operation field 

This is a ten-position field that contains a machine- 
language input/output instruction which the iocs 
schedules and executes. The B-address of this instruc- 
tion ties the iorw to a specific input/output area ( i.e., 
the B-address of this instruction is the low-order ad- 
dress of the relevant input/output area ) . 



error count field 

This is a two-position field. When an error results 
from execution of the instruction that appears in the 
Input/Output Operation Field, the iocs uses this field 
to maintain a count of the number of times the in- 
struction has been re-executed while attempting to 
correct the error. 

s ( CHANNEL status character ) FIELD 
This is a one-position field. The iocs places a character 
in this field when execution of the instruction that ap- 
pears in the Input/Output Operation Field results in 
an error. The bcd code of this character (i.e., the 
Channel Status Character) indicates the channel 
status indicators that were turned on by the error, 
with two exceptions. These execeptions are: (a) the 
B bit is not included in the bcd code of this character 
if the wlr operand of the dtf errcheck entry was 
omitted, even if the wrong-length-record indicator is 
on, and (b) if the relevant input/output operation 
was a disk operation and no data was actually trans- 
ferred by the operation; the 1 bit is included to indi- 
cate that this is the case, even though the Not Ready 
channel status indicator was not turned on by the 
operation. 

d (channel test character) field 
This is a one-position field. The character (i.e., the 
Channel Test Character) in this field becomes the 
d-modifier of a Branch External Indicator (bex) in- 
struction. 

The iocs uses this instruction to test for error condi- 
tions after execution of the instruction that appears in 
the Input/Output Operation Field. 

If the wlr operand of the dtf errcheck entry was 
specified for the file, and the file consists of Form 1 
or Form 2 records, the Channel Test Character is a 
group mark (#=)• ^ tne WLR operand was not speci- 
fied, or if the file consists of Form 3 or Form 4 
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Figure 104. iorw 
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records, this character is a segment mark ( -ttt- ) . If the 
fourth operand of the errcheck entry was specified, 
this character is the character that appears as that 
operand. 



IORW INDICATORS 

Fields Ql through Q6 are one-position fields. Each 
of these fields contains a single character. The hcd 
code of these characters is used to control the internal 
operation of the iocs. The* bits these characters may 
contain, and the significance of each bit, are sum- 
marized in Figure 105. 

The bits associated with each box shown in Figure 
105 are mutually exclusive (e.g., if the B bit appears, 
the A bit may not appear). The bit associated with 
boxes marked spare is always the low-order bit shown 
(i.e., A, 4, or 1). The programmer must keep this fact 
in mind if he plans to construct iorw's himself. A 
similar situation applies to the box marked internal. 
However, once the iorw is in use, the iocs may alter 
these bits. 

In the paragraphs that follow, Fields Q1-Q6 are 
discussed in detail. 

Ql: This field is reserved for the future use of the 
iocs. 

Q2: The bcd code of the character in this field in- 
cludes the 8 bit if the second operand of the dtf 
fileform entry was specified. If the bcd code includes 
the 4 bit, this operand was not specified. The bcd code 
of the character in this field includes the 2 bit if the 
ngeom operand was specified in the fileform entry 



for the file (i.e., the file is a Form E or Form F disk 
file). If the bcd code includes the 1 bit, the ngeom 
operand was not specified. 

Q3: The bcd code of the character in this field in- 
cludes the B bit, if a user-written error routine has 
been provided for the file with which the iorw is 
associated. If the bcd code includes the A bit, no 
such routine has been provided. (See the dtf "erraddr" 
entry. ) 

The bcd code of the character in this field includes 
the 2 bit, if a user-written service routine has been 
provided for the file with which the iorw is associated. 
If the bcd code includes the 1 bit, no such routine has 
been provided. ( See the dtf "intaddr" entry. ) 

Q4: The bcd code of the character in this field in- 
cludes the B bit, if the input/output area associated 
with the iorw has been released to the program (i.e., 
the Traffic Bit is on ) . The bcd code includes the A bit, 
if the associated input/output area has not been re- 
leased to the program (i.e., the Traffic Bit is off). 
(See "Interaction of the iocs Lists," for a discussion 
of when the Traffic Bit is set on and off.) The bcd 
code of the character in this field includes the 2 bit if 
the iocs is to make a programmed wrong-length- 
record check after execution of the instruction in the 
Input/Output Operation Field. If the bcd code in- 
cludes the 1 bit, this check is not made (see the dtf 
"errcheck" entry. ) 

Q5: The bcd code of the character in this field in- 
cludes the B bit (i.e., the Exception Bit is on) if: (a) 
an error or end-of-reel condition has occurred as a 
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Figure 105. iorw Indicators 
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result of execution of the instruction that appears in 
the Input/Output Operation Field, and (b) an exit is 
to be taken as a result of this condition to the error 
or end-of-file routine provided for the file by the pro- 
grammer. If the bcd code includes the A bit (i.e., the 
Exception Bit is off), no error or end-of-reel condi- 
tion has occurred. 

The bcd code of the character in this field includes 
the 2 bit if the iocs is to store the contents of the E- 
address or F-address register after execution of the 
instruction that appears in the Input/Output Opera- 
tion Field. If the bcd code includes the 1 bit, no such 
action is to be taken. ( See the dtf "errcheck" entry. ) 

Note: If the bcd code of the character in Field Q4 
includes the 2 bit, the code of the character in Field 
Q5 also includes the 2 bit. If the bcd code of the 
character in Field Q5 includes the 2 bit, the bcd code 
of the character in Field Q4 does not necessarily in- 
clude the 2 bit. 

Q6; The bcd code of the character in this field in- 
cludes the B bit if: (a) an error condition resulted 
from execution of the instruction in the Input/Output 
Operation Field, and (b) an exit is to be taken, as a 
result of this error condition, to the error routine 
provided for the file by the programmer. If the bcd 
code includes the 1 bit, no such error condition has 
occurred. 

The bcd code of the character in this field includes 
the 2 bit if the iocs is to make a Write Disk Check 
after execution of the instruction in the Input/Output 
Operation Field. If the bcd code includes the 1 bit, 
this check is not made. (See the dtf "errcheck" 
entry. ) 

Note: If the bcd code of the character in Field Q5 
includes the B bit, the code of the character in Field 
Q5 also includes the B bit. However, it should be 
noted that the converse is not necessarily true. 

ADDRESS REGISTER FIELD 

This is a five-position field. It is generated: (a) if the 
wlr operand of the dtf errcheck entry was specified 
for the relevant file, and the file consists of Form 3 or 
Form 4 records, or (b) if the store operand of the 
dtf errcheck entry was specified for the relevant file, 
regardless of the record form used by the file. 

The iocs stores, in this field, the length of the last 
record read after execution of the instruction that ap- 
pears in the Input/Output Operation Field if: (a) the 
file consists of variable-length records, and (b) the 
wlr operand was specified for the file. (The iocs 
compares the contents of this field to the contents of 
the relevant Block Character-Count to determine if a 



wrong-length record has been read. ) In all other cases, 
the iocs stores the contents of the E-address or F- 
address register in this field after execution of the 
relevant input/output operation. 

User-Coded lORW's 

The programmer can create an iorw by providing 
coding of the format shown in Figure 106. 



Line 

5 S 


Label 

6 15 


Operation 
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V 2P 30 « 40 ( 
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.... , 
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Figure 106. Coding the iorw 



The operand shown on Line 1 of Figure 106 must be 
either 00000 or the address of the low-order posi- 
tion of the Link Field of another iorw. The units 
position of this field must always be signed plus. The 
operand shown on Line 2 must be the name of the file 
(as it appears in the operand of the relevant dtf 
Header Line entry) with which the iorw is to be 
associated. The operands shown on Line 3 must be 
(in order) the x-control field, the B-address (i.e., the 
label referring to the appropriate input/output area), 
and the d-modifier of the instruction that is to appear 
in the Input/Output Operation Field of the iorw. The 
operand shown on Line 4 reserves the ten positions of 
core storage needed to contain the Error Count, the 
S, the D, and the Q fields of the iorw. The first three 
positions (i.e., the Error Count and S fields) must 
contain blank characters. The last seven positions 
should contain the actual characters the program- 
mer wants to appear in the D field and the Q fields. 
The operand shown on Line 5 is required only if the 
Address Register Field is to appear. 

Any iorw created by the programmer can be as- 
sociated with the relevant file by means of the dtf 
filelist entry. 

The following restrictions apply to user-coded 
iorw's: 

1. The Traffic Bit must be on if the file is not to be 
opened before it is used (i.e., the bcd code of the 
character in Field Q4 includes the B bit, but not the 
A bit). 

2. The low-order character of the x-control field of 
the instruction in the Input/Output Operation Field 
cannot be or 3, if the instruction is a disk instruction. 
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Modification of the IORW 

The contents of any field of an iorw can be modified 
during execution of the program, as long as the modi- 
fication preserves the intent of the field. 



System Monitor 

The System Monitor provides the iocs with the follow- 
ing information: 

1. If a file uses a unit-record device, the System 
Monitor provides a character indicating the channel 
to which that device is attached (i.e., the channel 
character). This character is placed in the x-control 
field portion of the Input/Output Operation Field of 
each iorw on the File List associated with the file. 

2. If a file uses a magnetic tape unit, the System 
Monitor provides: (a) the number of the unit, and 
(b) a character indicating the channel to which the 
unit is attached. This information is placed in the 
x-control field portion of the Input/Output Operation 
Field of each iorw on the File List associated with 
the file. 

3. If a file uses a module of 1301 Disk Storage, the 
System Monitor provides: (a) a character indicating 
the channel to which the module is attached, (b) the 
address of the first track of the physical unit currently 
assigned to the file, and (c) the Ending Track Ad- 
dress of the physical unit currently assigned to the 
file. This information is placed, respectively, in: (a) 
the x-control field portion of the Input/Output Opera- 
tion Field of each iorw on the File List associated 
with the file, (b) Field 3 of the File Table associated 
with the file, and (c) Field 4 of the File Table as- 
sociated with the file. 

The iocs automatically links with System Monitor 
to obtain this information whenever: 

1. A file is opened by means of an ioctl open 
macro-instruction. 

2. An end-of-reel condition occurs on a tape file 
for which an alternate unit (or units) has been speci- 
fied. 

3. An end-of-physical-unit condition occurs on a 
disk file for which an alternate physical unit (or 
units ) has been specified. 

The information provided by the System Monitor 
differs as follows: 

1. When a file is opened, the information provided 
refers to the Base Unit assigned to the file. 

2. When an end-of-reel or physical-unit condition 
occurs on a file, the information provided refers to the 
next alternate unit ( if any ) . 



Monitor Calling Sequences 

The System Monitor can provide the information dis- 
cussed above at times other than when a file is opened, 
or an end-of-reel, or end-of-physical-unit condition oc- 
curs on a file. To obtain this information at times other 
than those noted above, the programmer must enter 
the appropriate System Monitor calling sequences in 
his object program. The various System Monitor call- 
ing sequences are discussed in the material that 
follows. 

base/current sequence 

The Base/Current sequence causes the System Moni- 
tor to establish the Base Unit associated with the file 
as the Current Unit of the file. This sequence consists 
of the coding shown in Figure 107. 



Line 

S 5 


Label 

6 IS 


Operation 

16 20 
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0,1, 
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Figure 107. Base/Current Sequence 

The label filename shown on Line 1 must be the 
same label that appears in the operand field of the 
dtf Header Line entry for the affected file. 

alternate/current sequence 

The Alternate/Current sequence causes the System 
Monitor to establish the next Alternate Unit associated 
with the file as the Current Unit of the file. This 
sequence consists of the coding shown in Figure 108. 



Line 
J s 


Label 
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Operation 
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Figure 108. Alternate/Current Sequence 

The label anylabel shown on Line 3 of Figure 108 
refers to a user-written routine that is to be exited to 
if there is no Alternate Unit available to be estab- 
lished as the Current Unit. When this exit is taken, 
the System Monitor automatically establishes the 
Base Unit as the Current Unit. 

USE CURRENT UNIT SEQUENCE 

The Use Current Unit sequence must be entered in 
the user's source program subsequent to the coding 
for the Base/Current sequence or the Alternate/Cur- 
rent sequence (whichever is appropriate). The exact 
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point at which the Use Current Unit sequence is 
entered is not critical, as long as it appears in the 
user's object program: (a) after the relevant Base/ 
Current or Alternate/Current sequence, and (b) be- 
fore the next get or put macro-instruction that refer- 
ences the affected file. The Use Current Unit sequence 
consists of the coding shown in Figure 109. 
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Figure 109. Use Current Unit Sequence 



Fife Table 

The File Table is a group of fields that contain in- 
formation the iocs must have to schedule and execute 
input/output and related operations on a file. The 
information contained in the File Table is provided 
by dtf entries and the System Monitor. When a dtf 
statement is not provided for a file, the programmer 
must construct the File Table for that file. 

The fields of the File Table (Figure 110) are dis- 
cussed in the section that follows. 

Tape/Disk Prefix 

The File Table Tape/Disk Prefix consists of Fields 
1-4. If the file is a tape file all four fields appear. If 



Field 



Mnemonic Operand 



Explanation 



(Disk File Prefix) 
DCW xxxxx 

DCW xx 

DCW xx 



Address of user's Scramble Routine 
Number records per track 
Current Record 



DCW 
DCW 



AMTTTTHA 
TTTT 



5 FILENAME 
6 



9 

10 

11 

12LENGTHLBLDCW 



(All Devices) 

DCW 

DCW 

DCW 

DC 

DC 

DC 

DC 

DC 

DC 

DCW 

DCW 

DCW 



13 
14 



15 
16 



DCW 

DC(W) 

DC(W) 

DC(W) 

DC(W) 

DC(W) 

DCW 

DCW 



xxxxx 
/xxx/ 
xxxxx 

@x@ 
@x@ 
@x@ 
@x@ 
@x@ 
@x@ 

XX 

xxxxx 
xxxxx 
xxxxx 
xxxx 

@x@ 

@x@ 

@x@ 

@x@ 

@x@ 

xxxxx 

xxxxx 



17 
18 



(File Table Extension) 
DCW @x@ 

DCW xxxxx 

DC @xx@ 





DCW 




DC 


19EXTENLBL 


DC 




DC 




DC 




DC 




DC 


20 


DCW 


21 


DCW 


22 


DCW 


23 


DCW 


24 


DCW 


25 


DCW 



Starting Address 
Ending address 



File List Origin 

Symbolic Unit 

User EOF routine address 

File Indicator 1 

File Indicator 2 

File Indicator 3 

File Indicator 4 

File Indicator 5 

File Indicator 6 

Index register address 

Miscellaneous. 1 

Miscellaneous 2 

Miscellaneous 3 

Miscellaneous 4 

Error Indicator 1 

Error Indicator 2 

Error Indicator 3 

Error Indicator 4 

Error Indicator 5 

User error routine address 

User interrupt routine address 



Mnemonic Operand 



Explanation 



(Tape File Prefix) 
DCW EXTENLBL 



DCW 



DCW 
DCW 



@RNUR@ 



Address of File Table 

Extension 

Block counter. 

Reel counter. 
RWD/U options. 



Terminate table lookup character 
Label routine address 
Label exit indicator 



xxxxx 


Label routine address 


@xx@ 


Label exit indicator 


@x@ 


Label Indicator 1 


@x@ 


Label Indicator 2 


@x@ 


Label Indicator 3 


@x@ 


Label Indicator 4 


@x@ 


Label Indicator 5 


@x@ 


Record Form 


@xxxx@ 


Retention Period 


@xxxxx@ 


Creation date 


@xxxxxxxxxx@ 


File identifier 


@xxxxx@ 


File serial number 


@xxxx@ 


Reel sequence number 



Figure 110. Fields of the File Table 
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the file is a disk file, and the second and third op- 
erands of the dtf fileform entry have been specified 
for the file, all four fields appear. If the file is a disk 
file, and the second, but not the third, operand of the 
dtf fileform entry has been specified for the file, 
both subfields of Field 2 appear, as do Fields 3 and 4. 
For all other disk files, only the second subfield of 
Field 2, and Fields 3 and 4 appear. 

FIELD l 

For Form E disk files, this is a five-position field that 
contains the address of the programmer's scramble 
routine. For all other types of disk files, this field 
is omitted. For tape files that use labels the iocs is to 
process, this is a five-position field that contains the 
address of the File Table Extension that is to be used 
to process the labels of the file. For all other tape 
files this is a one-position field that contains a zero. 

FIELD 2 

For Form C and E disk files, this is a four-position 
field. In this case the first two positions of this field 
are a subfield that contains the number specified as 
the second operand of the dtf fileform entry; the 
last two positions are a subfield that initially contains 
zeros. Every time a disk record is read or written, the 
integer 1 is added to the second subfield. When the 
number in the second subfield equals the number in 
the first subfield, the second subfield is reset to con- 
tain zeros, and the Current Track Address (Field 3) 
is incremented by 1. If the file is a Form A, B, D, F, 
or G disk file, this is a two-position field that is re- 
served for the internal use of the iocs. For tape files, 
this is a five-position field that contains a count of 
the records (unblocked files) or blocks of records 
(blocked files) read from or written on the current 
reel of tape. Noise records (i.e., records less than 13 
characters in length), header and trailer labels, and 
tape marks are not included in this count. 

field 3 

For disk files, this is an eight-position field that con- 
tains the information shown in Figure 111 (i.e., the 
Current Track Address of the current physical unit). 
This information is initially supplied by the System 
Monitor. 

For input tape files, this is a two-position field that 
initially contains zeros. The programmer may place 
a signed or unsigned positive integer in this field that 

A M TTTT HA 

•-HA2 

Track Address 

Module 

Access Mechanism 



Figure 111. Current Track Address 



represents the number of reels that make up the file. 
Every time the iocs reads a complete reel of the file 
it decrements this integer by one. When this field 
contains all zeros, the iocs causes a branch to be taken 
to the programmer's end-of-file routine. If this field has 
been set to a positive integer by the programmer, the 
iocs ignores any lEOFb or lEORb label identifier en- 
countered in the trailer label of a reel of the file. If the 
file is an output tape file this field is not referenced 
by the iocs. 

field 4 

This is a four-position field. For disk files, this field 
contains the address (i.e., the End Track Address) of 
the last track of the current physical unit that is to 
be read or written by the iocs. This address is pro- 
vided by the System Monitor. It must be in the same 
module as the first track of the current physical unit. 
The iocs uses this field to determine when the last 
track of the current physical unit has been read or 
written. 

For tape files, this field contains the characters spe- 
cified in the four operand fields of the dtf rwdoptns 
entry. 

File Table Body 

The File Table Body consists of Fields 5-13. These 
fields appear regardless of the type of input/output 
device used by the file. 

FIELD 5 

This is a five-position field that is referred to as the 
File List Origin. It contains the address of the first 
iorw on the File List associated with the file. (See 
the discussions of List Origin and File List, under 
"The iocs Lists.") The units position of this field may 
be referred to by the label entered as the operand of 
the dtf Header Line entry for the file. When there 
are no iorw's on the File List, this field contains 00000. 

FIELD 6 

This is a five-position field that contains the address 
equivalent of the symbolic unit name entered as the 
second operand of the dtf symunit entry. This ad- 
dress is used by the System Monitor to provide certain 
information that is inserted in the iorw's associated 
with the file. (See the section, "System Monitor.") If 
the file is a disk file the System Monitor also uses this 
field to provide the information contained in Fields 
3 and 4. 

FIELD 7 

This is a five-position field that contains the address 
of the programmer's end-of-file routine. If the dtf 
eofaddr entry is omitted, this field contains zeros. 
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FIELD 8 

This is a six-position field that contains the File Indi- 
cators F1-F6. Each indicator is a single character ( see 
Figure 112). The bits associated with the boxes 
marked spare in Figure 112 are always the low-order 
bits shown (i.e., A, 4, or 1). The bits associated with 
each box are mutually exclusive (e.g., if the 4 bit 
appears the 8 bit may not appear). The file indicators 
are discussed in the paragraphs that follow. 

Fl: This indicator is the character specified by the 
dtf padchar entry written for the file. It is a blank 
character (b) if the padchar entry is omitted. 

F2: If the bcd code of this indicator includes the 
B bit, the Error Accept bit is said to be on. If the bcd 
code includes the A bit, the Error Accept bit is said 
to be off. The iocs sets the Error Accept bit on just 
before exiting to the error routine the user has pro- 
vided for the file. If the programmer does not set the 
Error Accept bit off before exiting from this error 
routine, the iocs, immediately after the error routine 
has been exited from, accepts the results of the input/ 
output operation, the execution of which caused the 
error routine to be entered. The iocs does this by 
setting the Traffic Bit of the affected iorw (i.e., the 
iorw that is then at the top of the File List associated 
with the file) off and placing the iorw on the bottom 
of the File List of the affected file. If the programmer 
does set the Error Accept bit off before exiting from 
his error routine, the iocs, immediately after the error 
routine has been exited from, re-executes the input/ 
output operation, the execution of which caused the 
error routine to be entered. 

F3: When this indicator is assembled, its bcd code 
includes the A bit. If the user replaces this A bit with 
a B bit, closes and then reopens the file, the System 
Monitor assigns to the file the last physical unit 
referenced by the file. ( Normally, the System Monitor 
assigns the Base Unit to a file when the file is opened. ) 

The bcd code of this indicator includes the 1 bit 
when it is assembled. If the user replaces this bit with 
a 2 bit and an end-of-reel or physical-unit condition 
is forced or encountered on the file, the next alternate 
physical unit is not assigned to the file by the System 
Monitor, as would normally be the case. Instead, the 
System Monitor assigns to the file the last physical 
unit referenced by the file prior to the end-of-reel or 
physical-unit condition. In addition, if the file is a disk 
file the iocs will cause a branch to be taken to the 
users end-of-file routine for the file. 

F4: If the bcd code of this indicator includes the 
B bit, the skip operand of the dtf erroptns entry has 
been specified for the file. If the bcd code includes the 
A bit, the accept operand of the dtf erroptns entry 



has been specified for the file, or the erroptns entry 
has been omitted altogether. If the bcd code of this 
indicator includes the 2 bit, the dtf fileform entry 
for the file specified that the file consists of Form 4 
data records. If the bcd code includes the 1 bit, the 
dtf fileform entry for the file specified that the file 
consists of Form 1, 2, or 3 data records. 

F5: If the bcd code of this indicator includes the 
B bit, an error or end-of-file condition has occurred 
on the file as a result of the last input/output opera- 
tion performed on the file. If the bcd code includes the 
A bit, no such condition occurred as a result of the 
last input/output operation. If the bcd code of this 
indicator includes the 2 bit, the dtf fileform entry 
specified that the file consists of blocked data records 
(i.e., Form 2 or Form 4). If the bcd code includes the 
1 bit, the dtf fileform entry specified that the file 
consists of unblocked records (i.e., Form 1 or Form 3). 

F6: This indicator notifies the iocs what type of 
input/output device is to be used by the file. This 
information is obtained from the dtf symunit entry. 

The possible device indicators are: 



INDICATOR 
1 

2 
4 



EXPLANATION 

1402 Card Reader, 1442 Serial Card 
Reader, 1011 Paper Tape Reader 
1402 Card Punch, 1403 Printer 
7330, 729 Magnetic Tape Units 
1301 Disk Storage 



FIELD 



This is a two-position field. It contains the last two 
digits of the address of the index register specified in 
the dtf index entry. If the dtf index entry is omitted, 
this field contains zeros. 



field 10 

This is a five-position field that initially contains zeros. 
If the dtf index entry was specified, this field contains 
the high-order address of the input/output area 
currently available to the user's object program. If 
the dtf index entry was not specified, this field con- 
tains: (a) the high-order address of the data record 
currently available to the using program, if the file is 
an input file, or (b) the high-order address of that 
portion of the current output area that is available to 
the using program, if the file is an output file. The 
iocs provides this information during execution of get, 

PUT, IOCTL OPEN, IOCTL RELSE, and IOCTL FEOR. 

If an exit has been taken to a user-written error or 
end-of-file routine, this field contains the return ad- 
dress to the series of instructions generated by the 
get or put macro-instruction that caused the exit to 
be taken. 
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BIT 
CONFIGURATION 


B 


A 


8 


4 


2 


1 


Fl 


PADDING CHARACTER 


F2 


ERROR ACCEPT 


SPARE 


SPARE 


ON 


OFF 




NORMAL 




NORMAL 


F3 


RESET TO BASE 


SPARE 


SET TO ALTERNATE 


NO 


YES 




NORMAL 


NO 


YES 


F4 


SKIP 


SPARE 


FORM 4 


YES 


NO 




NORMAL 


YES 


NO 


F5 


EXCEPTION BIT 


SPARE 


BLOCKED 


ON 


OFF 




NORMAL 


YES 


NO 


F6 


DEVICE CHARACTER 



Figure 112. File Indicators 



FIELD 11 

This is a five-position field that contains the informa- 
tion entered in the operand of the dtf blocksize entry. 
If the file consists of Form 1 or Form 3 records, this 
field is not used by the iocs. In these instances, the 
programmer is free to make use of this field for his 
own purposes. 

FIELD 12 

This is a five-position field. If the file is an input file 
made up of Form 2 or Form 3 records, it contains the 
low-order address +1 of the block of data records 
currently available to the using program. (The iocs 
uses this information during execution of get, put, 
ioctl open, iocTL close, and IOCTL feor. ) If the file 
is an output file: (a) that is made up of Form 4 
records, (b) for which the dtf length entry has been 
specified, and (c) that is to be processed by the 
put file,form4 macro-instruction, the programmer 
places in this field the length of the next record he is 
going to move into the current output area. (Under 
these conditions this field may be referred to sym- 
bolically by the operand of the dtf length entry.) 
The two high-order positions of this field are also used 
by the iocs as temporary storage for the last two char- 
acters of the current get/put calling sequence (i.e., 
the coding generated by the current get or put ) . 

FIELD 13 

This is a four-position field. If the file consists of Form 
2 records, this field contains the information entered 
in the operand of the dtf recsize entry. If the file is an 



output file that consists of Form 4 records, this field 
contains an integer equal to the number of positions 
in the current output area of the file that are occupied 
by data. 

This field is not used by the iocs if the file consists 
of Form 1 or Form 3 records, or if the file is an input 
file that consists of Form 4 records. In these instances, 
the programmer is free to make use of the field for 
his own purposes. 



FIELD 14 



This is a five-position field that contains the informa- 
tion entered in the second through sixth operands of 
the dtf erraddr entry. (The mnemonic used by the 
iocs to generate a character for this field is dcw, if the 
corresponding operand calls for an exit bypassing 
standard iocs error procedures. It is dc, if the corre- 
sponding operand calls for an exit only when the error 
condition or conditions specified cannot be corrected 
by the standard iocs error procedures. ) The iocs uses 
this information to determine under what conditions 
it is to branch to the error routine provided by the 
user for the file. This field must contain blanks if the 
dtf erraddr entry is omitted. 



FIELD 15 



This is a five-position field that contains the address of 
the error routine the programmer has provided for the 
file. (This field can be used by the programmer for 
his own purposes if the dtf erraddr entry is omitted 
and the dtf intaddr entry is included. If both dtf 
erraddr and intaddr entries are omitted, this field 
does not appear. ) 
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FIELD 16 

This is a five-position field that contains the address of 
the service routine the programmer has provided for 
the file. This field does not appear if the dtf intaddr 
entry is omitted. 

File Table Extension 

The File Table Extension consists of Fields 17-25. The 
iocs uses the information contained in these fields to 
process the tape labels used by the file. If the file does 
not use labels, these fields do not appear. Most of the 
information contained in these fields is provided by 
the dtf label and check entries for the file ( e.g., the 
label entry supplies the information for Fields 21-25 ) . 
The programmer may update or alter the information 
contained in these fields (see "Appendix E"). When 
these fields are generated, they precede the balance 
of the File Table in core storage, but they do not 
necessarily immediately precede the balance of the 
File Table. 

FIELD 17 

This is a one-position field that contains a character 
normally supplied by the iocs. This character is used 
to terminate the table lookup operations the iocs per- 
forms on Field 18. If the programmer has specified the 
dtf lineI above entry for the file., that entry supplies 
this character. 

FIELD 18 

This field contains from one to eight entries if the 
dtf lineI or line2 entries have been specified; from 
9 to 16 entries if lineI above was specified. Each 
entry consists of a dcw followed by a dc. The dcw 



specifies the address of a label routine written by the 
user. The dc specifies the point in the iocs tape label 
routines at which the iocs is to branch to that routine. 

FIELD 19 

This is a five-position field that contains the Label 
Indicators L1-L5. Each of these indicators consists of 
a single character. (See Figure 113.) The bits as- 
sociated with the boxes marked spare in the figure 
are always the low-order bits shown (i.e., A, 4, or 1). 
The bits associated with each box are mutually ex- 
clusive (e.g., if the 2 bit appears, the 1 bit may not 
appear ) . 

The label indicators are discussed in the material 
that follows. 

LI: The bcd code of this indicator includes the 1 bit 
if the file serial number has been entered as an op- 
erand of the dtf label entry. The bcd code includes 
the 2 bit if the file serial number has not been entered. 
(If the bcd code includes the 2 bit and the file is a 
tape output file, the iocs places the reel serial number 
of the first reel of the file in Field 24 of the File Table 
prior to writing the new output header label. If the 
bcd code includes the 1 bit, the iocs places the speci- 
fied file serial number in Field 24. ) 

L2: The bcd code of this indicator includes the B 
bit if nonstd appears as the second operand of the 
dtf label entry for the file. If the file uses standard 
labels, the bcd code of this indicator includes the A 
bit. The bcd code of this indicator includes the 2 bit 
if 120 appears as the first operand of the dtf label 
entry for the file. The bcd code includes the 1 bit if 
80 appears as the first operand, or the dtf label 
entry was not specified for the file. 
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Figure 113. Label Indicators 
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L3: The bcd code of this indicator includes the B bit 
if the ser operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the dtf check entry was 
not specified for the file. The bcd code of this indicator 
includes the 2 bit if the id operand is specified in the 
dtf check entry for the file. The bcd code includes the 
1 bit if this operand is not specified or the check entry 
was omitted. 

L4: The bcd code of this indicator includes the B bit 
if the seq operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the check entry was 
omitted. 

The bcd code of this indicator includes the 2 bit if 
the dat operand is specified in the dtf check entry 
for the file. The bcd code includes the 1 bit if this 
operand is not specified, or the check entry was 
omitted. 

L5: The bcd code of this indicator includes the B bit 
if the cnt operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the check entry was 
omitted. The bcd code of this indicator includes the 
2 bit if the ret operand is specified in the dtf check 
entry for the file. The bcd code includes the 1 bit if 
this operand is not specified, or the check entry was 
omitted. 

ALL: If the all operand is included in the dtf 
check entry for the file, the bcd code of indicators L3, 
L4, and L5 is B-4-2. 

field 20 

This is a one-position field that contains a character 
indicating the form of the records on the file, F indi- 
cates Form 1, W indicates Form 2, B indicates 
Form 3, and X indicates Form 4. 

field 21 

This is a four-position field that contains the retention 
period. If the file uses 80-character labels the high- 
order position of this field contains a — 

field 22 

This is a five-position field that contains the creation 
date. 

field 23 

This is a ten-position field that contains the file identi- 
fication. 

FIELD 24 

This is a five-position field that contains the file serial 
number. 



FIELD 25 

This is a four-position field that contains the reel 
sequence number. If the file uses 80-character labels 
the high-order position of this field contains a — . 



IOCS Lists 

An iocs List is a collection of iorw's grouped by the 
iocs for a specific purpose (e.g., to schedule assign- 
ment of access mechanisms to iorw's that represent 
requests for disk input/output operations ) . 

List Origin: Each iocs list has a List Origin. This 
is a five-position field that contains the address of the 
low-order position of the Link Field of the first iorw 
on that list. If the list is temporarily without iorw's 
the List Origin contains 00000. 

The Link Field of each iorw on an iocs list contains 
the address of the low-order position of the Link Field 
of the next iorw on the same list. There is one ex- 
ception to this rule. The Link Field of the last iorw 
on a list contains 00000 or 00000. These zeros indicate 
to the iocs that the end of the list has been reached. 

In addition to a List Origin, every Read/Write List 
maintains a List End Address. This is a five-position 
field that contains the address of the low-order posi- 
tion of the Link Field of the last iorw on the list. If a 
Read/Write List is temporarily without iorw's, the 
List End Address contains the address of the low-order 
position of the List Origin of that list. 

FILE LISTS 

One File List is associated with every File Table. 
(This is a function of the dtf ioareas or the dtf 
filelist entry.) The iorw's on File Lists associated 
with sequential files represent completed input/output 
operations. The input/output area associated with the 
first iorw on such a File List is the input/output area 
currently available to the user's program. The iorw's 
on File Lists are processed in the order in which they 
appear on these lists. The List Origins of File Lists 
are automatically generated in the File Tables with 
which the lists are associated. 

disk module lists 

There is one Disk Module List for each module of 
1301 Disk Storage defined at System Generation. The 
List Origins of these lists are contained in the Resi- 
dent iocs. The iorw's on these lists: (a) represent 
requests for Seek Disk operations, or (b) indicate that 
the relevant Seek Disk operation, or its associated 
input/output operation, is in the process of being 
executed by the iocs. 

The last iorw on such a list contains 00000 in its 
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Link Field. (This is the only instance when 00000 
may appear in the Link Field of an iorw. ) If_the list 
is void, the List Origin of the list contains 00000. 

read/write lists 

The iocs maintains one Read/Write List for each data 
channel available to using programs. The iorw's on 
Read/ Write Lists represent requests for input/output 
operations. They are normally processed in the order 
in which they appear on these lists. This is not the 
case, if: (a) a get or put other than a get,defer or 
put,defer is issued and (b) the iorw associated with 
the requested input/output operation is not available 
on the relevant File List. Under these conditions, the 
iocs causes the appropriate Read/Write List to be 
searched until the affected iorw is located. If the 
affected iorw is not at the top of the list, it is im- 
mediately moved to the top. This ensures that the 
requested operation is the next operation executed on 
the affected channel. The List Origins of Read/Write 
Lists are contained in the Resident iocs. 

SERVICE LISTS 

A Service List is associated with every service routine 
whose label appears as the operand of a dtf intaddr 
entry. The iorw's on these lists represent requests 
pending for entry into user- written service routines. 

The List Origins of these lists immediately precede 
the service routines with which they are associated. 
They may be referred to by the label of the relevant 
service routines. 



PROGRAM LIST 

The iocs maintains one Program List. The entries on 
this list are not iorw's. They are five-position fields 
that contain addresses which identify service routines 
that have iorw's on their associated Service Lists. The 
Resident iocs places these entries on the Program 
List, the most recent entry at the top of the list. This 
is a departure from the procedure followed in adding 
entries to the other iocs Lists. When a new entry is 
added to the other iocs Lists, it is added to the bottom 
of the list. 

When all the iorw's on the Service List of the rou- 
tine associated with the entry at the top of the Pro- 
gram List have been processed, the Resident iocs 
removes the affected entry from the Program List. It 
then places the next entry at the top of the list and 
causes the service routine associated with that entry 
to be entered. This process is repeated until the Pro- 
gram List is devoid of entries. When the list becomes 
void, the Resident iocs restores the status of the user's 
main-line program and causes a branch to be taken to 



the interrupted instruction in the user's main-line pro- 
gram. The List Origin of the Program List is in the 
Resident iocs. 

Interaction of the IOCS Lists 

The flow of iorw's between the iocs Lists is discussed 
in the paragraphs that follow. 

When the iocs encounters a get or put macro- 
instruction in the user's program, the Resident iocs 
scans the appropriate File List until it encounters an 
iorw whose Traffic Bit is off. The Resident iocs then 
sets the Traffic Bit of the affected iorw on and makes 
the input/output area associated with the iorw avail- 
able to the user's program. 

When the Resident iocs scans the File List, it sends 
all the iorw's whose Traffic Bits are on to the bottom 
of the appropriate Read/Write List. (See Path 1, 
Figure 114.) 



File List 



Read/Write List- 




Figure 114. Interaction Between File Lists and Read/Write 
Lists 



Note: In the case of disk files, when the Resident 
iocs scans a File List, it sends all the iorw's whose 
Traffic Bits are on to the proper Disk Module List, 
rather than to the appropriate Read/Write List. (See 
Path 1, Figure 115. ) 



Disk Module List 




Figure 115. Interaction of File Lists and Disk Module Lists 

When an iorw that has been sent to a Read/Write 
List reaches the top of that list (i.e., the iorw's that 
preceded it have been processed and removed from 
the list), execution of the instruction in the Input/ 
Output Operation Field of the iorw is begun. The 
iorw is then removed from the Read/Write List and 
saved until execution of the relevant instruction has 
been completed. If execution of the instruction does 
not result in an error, the Resident iocs sets the 
Traffic Bit of the affected iorw off, and places it on 
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the bottom of the relevant File List. (See Path 2, 
Figure 114. ) 

If execution of the instruction resulted in an error 
condition, or combination of conditions, that the pro- 
grammer has specified are to cause the iocs to: (a) 
bypass the normal iocs, error correction procedures, 
and (b) exit to the error routine the programmer has 
provided for the file, the Resident iocs performs the 
following functions: 

1. Returns the affected iorw to the bottom of the 
appropriate File List. (See Path 2, Figure 114.) 

2. Removes all other iorw's associated with the 
affected file from the relevant Read/Write List ( start- 
ing at the top of the list), and places them (in the 
order in which they are removed) on the bottom of 
the File List. (See Paths 3 and 4, Figure 114. ) 

If execution of the instruction resulted in an error 
condition, or combination of conditions, that the pro- 
grammer has specified are to cause the iocs to: (a) 
execute the normal iocs error procedures, and (b) 
enter the error routine the programmer has provided 
for the file only if the error or errors could not be cor- 
rected by the normal error procedures, the Resident 
iocs: 

1. Performs the functions described in item 2 above, 
if the error condition or conditions could not be cor- 
rected, or 

2. Places the affected iorw on the bottom of the 
appropriate File List (see Path 2, Figure 114), if the 
error condition or conditions were corrected. 

If execution of the instruction resulted in an error 
condition, or conditions, for which the programmer 
has not specified an exit to the error routine he has 
provided for the file, the affected iorw is placed on 
the bottom of the appropriate File List (see Path 2, 
Figure 114). This is not the case, however, if the 
skip operand of the dtf erroptns entry was specified 
for the file. If the skip operand was specified, the 
affected iorw is retained at the top of the appropriate 
Read/Write List so that the relevant instruction can 
be re-executed by the iocs. 

If execution of the instruction: (a) did not result 
in an error condition, or combination of conditions, 
that the programmer has specified are to cause the 
iocs to exit to the error routine the programmer has 
provided for the file, (b) did not result in an error 
condition of any kind if the skip operand of the dtf 
erroptns entry has been specified for the file, and ( c ) 
the programmer has specified that a user-written serv- 
ice routine has been provided for the file, the Resident 
iocs takes the affected iorw off the top of the Read/ 
Write List (see Path 1, Figure 116) and places it on 
the bottom of the appropriate Service List. The 



Resident iocs then causes the service routine pro- 
vided for the file to be entered. At this time, the 
Resident iocs sets the Traffic Bit of the iorw off. 

The programmer may perform any function he 
desires within a service routine; however, the last 
instruction of every user-written service routine must 
be the ioctl exit,accept or the ioctl exit,delete 
macro-instruction. If the ioctl exit,accept is the last 
instruction, the Resident iocs takes the affected iorw 
off the top of the relevant service routine Service List 
(see Path 2, Figure 116) and places it on the bottom 
of the appropriate File List. If the last instruction is 
ioctl exit,delete the Resident iocs notes: (a) that 
the iorw has been removed from the relevant Service 
List (see Path 3, Figure 116), and (b) that control 
of the iorw has been assumed by the user. 



File List 



Read/Write List 



Service List 




Figure 116. Interaction of File Lists, Read/Write Lists and 
Service Lists 



IOCS Error Procedures 

Upon completion of every input/output operation 
performed on a file, a bex (Branch External Indicator) 
instruction is executed. The character found in the 
D (Channel Test Character) Field of the relevant 
iorw becomes the d-character of this instruction. 

If a branch is taken as a result of executing the bex 
instruction (i.e., a channel status indicator, whose as- 
sociated bcd bit matches a bit included in the bcd 
code of the d-character of this instruction, was turned 
on as a result of the input/output operation), the 
iocs Error Control routine is entered. If a branch is 
not taken, the next sequential instruction of the user's 
program is executed. 

Error Control Routine 

The primary function of the Error Control routine is 
to determine if and when a particular iocs error rou- 
tine is to be entered. The operation of the Error Con- 
trol routine, prior to entry into a particular iocs error 
routine, is: 

1. When control passes to the routine, it stores the 
Channel Status Character (i.e., a character whose 
bcd code indicates which channel status indicators 
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were turned on upon completion of the relevant in- 
put/output operation) with appropriate alterations, 
in the S Field of the affected iorw. Alterations to the 
Channel Status Character are discussed under "S 
(Channel Status Character) Field." 

2. The Error Control routine then attempts to match 
the Channel Status Character with one of the char- 
acters in Field 14 of the relevant File Table that is 
tagged with a word mark. 

3. If the Channel Status Character does not match 
a character in Field 14 that is tagged with a word 
mark, the Error Control routine causes a branch to be 
taken to the appropriate iocs error routine. 

4. If the Channel Status Character matches a char- 
acter in Field 14 that is tagged with a word mark, the 
Error Control routine examines indicator Q3 of the 
affected iorw to determine if a user-written error 
routine has been provided for the relevant file. 

5. If no such routine has been provided, the iocs 
error routines are bypassed and the affected input/ 
output operation is processed as if it were error free. 

6. If a user-written error routine has been provided, 
the Error Control routine: (a) sets the Exception Bit 
and Error Bit in the affected iorw on, ( b ) places the 
affected iorw on the bottom of the relevant File List 
with its Traffic Bit set off, and (c) removes all the 
iorw's associated with the affected file from the ap- 
propriate Read/Write List (starting at the top of the 
list) and places them (in the order in which they were 
removed from the Read/Write List) on the relevant 
File List (Traffic Bits set on). 

The Error Control routine also performs certain 
operations if an iocs error routine is unable to correct 
an error condition directed to it for correction. These 
operations are: 

1. When an iocs error routine cannot correct an 
error, control passes to the Error Control routine which 
attempts to match the Channel Status Character in 
the affected iorw with a character in Field 14 of the 
relevant File Table. 

2. If the Channel Status Character in the S Field of 
the iorw does not match a character in Field 14, the 
Error Control routine checks the fourth File Indicator 
(F4) of the relevant File Table. 

3. If the bcd code of F4 includes the B bit (i.e., the 
skip operand of the dtf erroptns entry has been speci- 
fied for the file), the Error Control routine retains the 
affected iorw at the top of the relevant Read/Write 
List with its Traffic Bit set on (i.e., schedules im- 



mediate re-execution of the instruction that appears 
in the Input/Output Operation Field of the iorw). 

4. If the bcd code of F4 includes the A bit (i.e., the 
accept operand of the dtf erroptns entry has been 
specified for the file, or the erroptns entry has been 
omitted altogether), the Error Control routine places 
the affected iorw on the bottom of the relevant File 
List with its Traffic Bit set off. 

5. If the Channel Status Character matches a char- 
acter in Field 14, the Error Control routine examines 
Field Q3 of the affected iorw to determine if a user- 
written error routine has been provided for the file. 

6. If such a routine has been provided, the Error 
Control routine: (a) sets the Exception Bit and the 
Error Bit in the affected iorw on, (b) places the af- 
fected iorw on the bottom of the appropriate File List 
with its Traffic Bit set off, and (c) removes all the 
iorw's associated with the affected file from the ap- 
propriate Read/Write List (starting at the top of the 
list) and places them (in the order in which they 
were removed from the Read/Write List) on the rele- 
vant File List (Traffic Bits set on). 

7. If this routine has not been provided, the affected 
input/output operation is processed as if it were error 
free. 

Error Routines 

The iocs provides an error routine for each type of 
input/output device specified by the using installation 
at System Generation. Each iocs error routine attempts 
to correct the error conditions routed to it for correc- 
tion by re-executing the relevant input/output opera- 
tions, or by other means peculiar to the affected type 
of input/output device. 

Whenever an iocs error routine causes an input/ 
output operation to be re-executed, the number in 
the Error Count Field of the affected iorw is in- 
cremented by one and the Channel Status Character 
of the iorw is replaced with a blank character. If the 
error recurs, the operation is retried until the number 
in the Error Count Field equals a maximum value that 
is determined by the type of device and whether the 
device is involved in reading or writing data. When 
this maximum value is reached, the error is considered 
uncorrectable and the affected error routine causes a 
branch to be taken to the Error Control routine. 

If the error is corrected, the affected iocs error 
routine places the relevant iorw on the bottom of the 
appropriate File List with its Traffic Bit set off. 
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Appendixes 



Appendix A: Shared Input/Output Areas 

Two programming schemes that allow an input and an 
output file to share the same input/output areas are 
discussed in this section. 

Two File/Three Area Overlap Programming 

A programming scheme that allows one input and 
one output file sharing the same three input/output 
areas to be processed in a manner that provides for 
the overlapping of read/write and processing opera- 
tions is discussed in the paragraphs that follow. This 
scheme allows records to be read into, processed in, 
and written out of the same input/output area. 

To use this scheme, the program must be initialized 
as follows: (All labels used in this example are for 
illustrative purposes only. ) 

1. Two files, one an input file labeled infile, one 
an output file labeled outfile, are defined. 

2. Three input/output areas, labeled areaI, area2, 
and area3, respectively, are defined. 

3. Three iorw's are generated, and one is labeled. 
Two of the iorw's are generated by means of the dtf 
ioareas entry included in the dtf statement defining 
infile, with areaI and area2 as its first and second 
operands. The third iorw is generated and labeled by 
means of the dtf ioareas entry included in the state- 
ment defining outfile, with area3 as its first operand 
and outiorw as its fourth operand. 

4. infile and outfile are opened (see Lines 1 and 
2 of Figure 117). 

5. The Traffic Bit of the iorw labeled outiorwa is 
set off ( see Line 3 ) . 

Once the program has been initialized, the two files 
are processed as follows: 

1. The iocs is requested to make the next logical 
record from infile available in the specified input/ 
output area ( see Line 4 ) . 

2. The last record made available by the iocs is 
processed ( see Line 5 ) . 

3. The program is taken out of Priority Alert (see 
Line 6). 

4. The address of the low-order position of the Link 
Field of the iorw on the top of the File List associ- 
ated with infile is stored in index register 15 (see 
Line 7 ) . 



5. The iorw on the top of the File List associated 
with infile is removed from that list and the next 
iorw on the list (if any) is moved to the top of the 
list ( see Line 8 ) . 

6. The address of the File List Origin associated 
with outfile is placed in the File List Address Field 
of the iorw that was removed from the File List 
associated with infile by Step 5 (see Line 9). 

7. The iorw that was at the top of the File List as- 
sociated with outfile (if any) is linked to the iorw 
that is to be placed on the File List associated with 
outfile by Step 8 (see Line 10). 

8. The iorw that was removed from the File List 
associated with infile by Step 5 is placed at the top 
of the File List associated with outfile ( see Line 11 ) . 

9. The x-control fields of the iorw's linked to the 
File List of outfile are initialized by the System 
Monitor (see Lines 12 and 13). 

10. The iocs is requested to write the last record 
processed by the using program on outfile ( Line 14 ) . 

11. The program is taken out of Priority Alert (see 
Line 15). 

12. The address of the iorw on the top of the File 
List associated with outfile is stored in index register 
15 ( see Line 16 ) . 

13. The iorw on the top of the File List associated 
with outfile is removed from that list and the next 
iorw on the list (if any) is moved to the top of the 
list (see Line 17). 

14. The iorw that was at the top of the File List 
associated with infile (if any) is linked to the iorw 
that is to be placed on the File List associated with 
infile by Step 15 (see Line 18). 

15. The iorw that was removed from the File List 
associated with outfile by Step 13 is placed at the 
top of the File List associated with infile (see Line 
19). 

16. The address of the File List Origin associated 
with infile is placed in the File List Address Field of 
the iorw that was removed from the File List as- 
sociated with outfile by Step 13 (see Line 20). 

17. The x-control fields of the iorw's linked to the 
File List of infile are initialized by the System Moni- 
tor ( see Lines 21 and 22 ) . 

18. A branch is executed to Step 1 (see Line 23). 
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Figure 117. Two File/Three Area Overlap Programming 



Two File/Two Area Overlap Programming 

A programming scheme that allows one input file and 
one output file that share the same two input/output 
areas to be processed in a manner that provides for 
the overlapping of read/write and processing opera- 
tions is discussed in the material that follows. This 
scheme is efficient if the time required to process a 
record read by the iocs is relatively short compared 
to the time required to read the record (get) from 
the input file or write the record (put) on the output 
file. This scheme is only applicable to files made up of 
unblocked records. 

To use this scheme, the program is initialized as 
follows: (All labels used in this example are for illus- 
trative purposes only. ) 

1. Two files, one an input file labeled infile, the 
other an output file labeled outfile, are defined. 

2. Two input/output areas, one labeled areaI, the 
other labeled area2, are defined. 

3. Two iorw's are generated and labeled; one by 
means of a dtf ioareas entry included in the dtf 
statement defining infile, with areaI as its first op- 
erand and iniorw as its fourth operand; the other by 
means of a dtf ioareas entry included in the dtf 
statement defining outfile, with areaI as its first 
operand and outiorw as its fourth operand. 

4. A one-position field labeled switch is defined. 

5. infile and outfile are opened (see Lines 1 and 
2 of Figure 118). 



Once the program has been initialized, the two files 
are processed as follows: 

1. The character A is placed in switch ( see Line 3 ) . 

2. The low-order address of areaI is made the 
B-address of the input/output instruction in outiorwa 
( see Line 4 ) . 

3. The Traffic Bit in outiorwa is set off (see 
Line 5 ) . 

4. The iocs is requested to make the next logical 
record from infile available in the input/output area 
whose address appears as the B-address of the instruc- 
tion contained in iniorwa ( see Line 6 ) . 

5. The low-order address of area2 is made the 
B-address of the input/output instruction contained in 
iniorwa ( see Line 7 ) . 

6. A branch is executed to process if the sign of the 
contents of switch is minus ( see Line 8 ) . 

7. The contents of switch is subtracted from itself 
( see Line 9 ) . 

8. The iocs is requested to make the next logical 
record from infile available, on a deferred basis, in 
the input/output area whose address appears as the 
B-address of the instruction contained in iniorwa 
( see Line 10 ) . 

9. The iocs is requested to write on outfile the 
last record processed by the using program (see Line 
11). 

10. The low-order address of area2 is made the 
B-address of the input/output instruction contained in 
outiorwa ( see Line 12 ) . 

11. A branch is executed to process if the sign of 
the contents of switch is minus ( see Line 13 ) . 

12. The iocs is requested to write on outfile, on a 
deferred basis, the last record processed by the using 
program ( see Line 14 ) . 
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Figure 118. Two File/Two Area Overlap Programming 



Appendixes 5^ 



13. A branch is executed to the instruction on Line 
6 ( see Line 15 ) . 

14. The contents of the B-address register are placed 
in the instruction on Line 18 ( see Line 16 ) . 

15. The current data record is processed (see Line 
17). 

16. A branch is executed to the address saved by the 
instruction on Line 16 ( see Line 18 ) . 



Appendix B: Modification of GET and PUT 
M acro-lnstructions 

The coding generated by all get and put macro-in- 
structions includes the sequence of instructions shown 
in Figure 119. 



Line 



fixi. 



0,5, 
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Figure 119. get/put Calling Sequences 

The instruction shown on Line 1 of Figure 119 
causes the user's program to be removed from Priority 
Alert and a branch to be executed to the Resident 
iocs at /pet/. The label filename shown on Line 2 
must be the same label that appears as the operand of 
the dtf Header Line entry for the file. The character 
represented by the alpha symbol shown on Line 3 
becomes the d-character of the input/output opera- 
tion requested by the relevant get or put macro- 
instruction. If this operation is a read operation the 
DC statement shown on Line 3 is assembled containing 
v Jie character R. If this operation is a write operation 
the dc statement is assembled containing the char- 
acter W. The dcw statement shown on Line 4 indicates 
whether the relevant get or put macro-instruction is 
a get file,defer or put file,defer. The statement is 
assembled containing an S if this is the case. It is 
assembled containing a blank character if this is not 
the case. 

The programmer may alter the d-character of the 
input/output operation discussed above. He may do 



this by placing in the operand field of the dc state- 
ment shown on Line 3 of Figure 119 one of the fol- 
lowing characters: 

CHARACTER RESULTANT INPUT/OUTPUT OPERATION 

$ Read to interrecord gap or end of core. 

X Write to end of core. 

Q Alter read instruction to a No Operation 

(NOP) instruction. 
V Alter write instruction to a No Operation 

(NOP) instruction. 

If the programmer changes the character in the 
operand field of the dc statement shown in Figure 119 
to $ or X, he must also change the channel character 
in the iorw at the top of the File List associated with 
the affected file. This channel character is assembled 
as an @ (i.e., overlap mode, channel 1) or as an 
(i.e., overlap mode, channel 2). This channel char- 
acter must be changed to a % (i.e., non-overlap mode, 
channel 1) or a □ (i.e., non-overlap mode, channel 
2). The reason for this change is that Read/Write 
to End of Core operations must always be executed 
in non-overlap mode on the ibm 1410. This channel 
character must be altered before the modified get or 
put macro-instruction is encountered in the using pro- 
gram. 



Appendix C: IOCS Console Messages 

This section provides explanations of the iocs console 
messages that are of interest to programmers who use 
the iocs. 

Error Messages 

All iocs error messages conform to the format shown 
in Figure 120. 

The message number shown in Figure 120 is con- 
stant. The two-character mnemonic ee indicates the 
type of error that has occurred (e.g., dc indicates that 
a Data Check has occurred). The bcd code of the 
Channel Status Character indicates which channel 
status indicator(s) have been turned on as a result 
of the error. If the input/output operation that re- 
sulted in the error was a tape read operation, the 
last field of the error message contains an integer 
equal to the number of characters transferred into 
core storage as a result of the operation. If the opera- 



Message 

Number 



10101 



Error 
Type 



i Channel Status 

I Character 

H 



EE 



Input/Output 
Instruction 



xxxxxxxxxx 



Tape Input Record Length 
or Disk Address 



Figure 120. iocs Error Message Format 
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.Channel 
Error Status 
Type . Character 


Affected 
Input/Output 
Device Type 


Explanation 


Action 


8 

O 

Z 


NR.l 


Tape, disk, 
card reader, 
card punch, 
printer. 


The relevant device (e.g., module of 1301 Disk Storage) is 
not ready. 


Ready the device. 


NR|/ 


Disk 


The IBM 7631 File control is not ready. 


Ready the 7631 . 


nr]j 


Disk 


The addressed access mechanism is inoperative. 


Ready the access. 


u 

V 

U 

o 



o 


DCl4 


Tape, disk, 
card reader, 
card punch, 
printer 


Tape Input Operation: (a) If record length is greater than 12 

characters a backspace followed by a read operation has been 

executed 99 times. 

(b) If record length is 12 characters or less, ten consecutive 

noise records have been read without changing the B-address 

of the affected input instruction. 1 This indicates that the 

relevant tape unit has been set to the wrong density. 

Tape Output Operation: A backspace, a skip and blank tape, 

and a write operation have each been executed, in sequence, 

25 times. 

Disk: The relevant input/output operation has been re-executed 

4 times. 

Card Reader: The last card read is in error. 

Card Punch: Machine parity error. The card is not punched. 
Printer: Machine parity error. The line is not printed. 


(a) None. 

(b) Set the relevant 
tape unit to the correct 
density. 

None. 

None. 

Run out card deck and re- 
load. Make the card 
reader Ready. 
Make the device Not 
Ready, then Ready. 
Make device Not 
Ready, then Ready. 


DC '5 


Disk 


The relevant input/output operation has been re-executed 
5 times. 


None. 


DC|M 


Tape, disk, 
card reader 


See "DC4" above. 


See "DC4." 


DC @ 


Tape 


See "DC4" above. 


See "DC4." 


c 



'"5 

s 


UC 8 


Card punch, 
printer 


Card Punch: An incorrect card has been punched. The erroneous 
card has been selected into stacker 0. 

Printer: A timing error or hammer fire check has occurred. The 
line is not printed. 


Make the device Not 
Ready, then Ready. 
Make the device Not 
Ready, then Ready. 


s 

u 

Ill 




wlI- 


Tape, disk 
card reader, 
card punch, 
printer 


Tape Input Operation: The input operation has been re-executed 
9 times. 

Tape Output Operation: The output operation has been re- 
executed 25 times. 

Disk: The input/output operation has been re-executed four times. 
Card Reader: The input/output operation has not been re-executed. 
Card Punch: The input/output operation has not been re-executed. 
Printer: The input/output operation has not been re-executed. 


None. 

If the error persists on 

the same record, the 

program should be 

terminated. 

None. 

None. 

None. 

None. 


WLiQ 


Tape 


Tape Input Operation: A tape mark has been read by the IOCS, 
but it has been determined that the end of the relevant data file 
has not yet been reached. 


None. 


S -o 
u c 
« 2 

o£ 
"" 

z 


NF|Z 


Disk 


The input/output operation has been re-executed 4 times, the 
access mechanism has been recalibrated, and the operation 
has been re-executed an additional four times. 


If the message is re- 
peated for the same 
record, the program 
should be terminated. 


o 

z "■ 


IT J V 


Disk 


The relevant access mechanism has been recalibrated and the 
input/output operation has been re-executed one time. 


If the message is re- 
peated for the same 
record, the program 
should be terminated. 


5 U 


MD| V 


Disk 


Data check, no transfer, and condition indicators have 
resulted from a disk operation. 


None. 


'5 o 


CCI8 


Disk 


A 7631 circuit check has occurred. This input/output operation 
has been re-executed one time. 


None. 


CClQ 


Disk 


See "CC8," above. 


See "CC8." 


1301 Circuit Check 
Invalid Operation 
Write Disk Check 


OpU 


Disk 


The input/output operation has been re-executed one time. 


If the message is re- 
peated for the same 
record, the program 
should be terminated. 


z"> 


ss'-b 


Card Reader 


Two UNCTL FILE ,SSF,d macro-Instructions have been executed 
without an intervening Read A Card instruction that contains 9 
in the units position of its x-control field. Two Read a Card in- 
structions with 9 in the units position of their x-control fields 
have been executed without an intervening UNCTL FILE,SSF,d 
Macro-instruction. 


None. 


£ 3 

"C jE 

5-= 


W1| D 


Disk 


Write operation was attempted, but write inhibit switch 
on 7631 is ON. 


Turn Switch OFF, or 
terminate program. 


c 

o b 

c t 

J* LLJ 

c 


UEP J 


Disk 


The IOCS cannot determine the exact nature of the error. 
It is looping on the operation that caused it. 


Terminate program. 



Figure 121. Error Type — Channel Status Character 
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tion was a disk operation, the last field contains the 
relevant disk address, in the form shown in Figure 111. 
The various combinations of characters that may 
appear in the error type and channel status character 
fields of iocs error messages are described in Figure 
121. 

Tape Label Messages 

The iocs provides three tape label messages. These 
messages are described in Figure 122. 



Message 


Explanation 


Operator Action 


10102cu xxxxx 


The block count of the affected input 
tape trailer label does not equal the 
block count accumulated for the reel 
by the IOCS, (cu is the channel and 
unit of the affected tape; xxxxx is the 
difference between the IOCS block 
count and the block count, on the 
reel.) 


None 


30101 cu 


One or more fields of the affected 
input tape header label do not match 
the corresponding field(s) of the File 
Table Extension used to check the 
label, (cu is the channel and unit 
of the affected tape.) 


The IOCS can be 
directed to accept 
the tape, or to re- 
execute the label 
check with a differ- 
ent reel mounted. 

1 . Press Inquiry 
Request key. 

2. To re-execute, 
enter $8R; to ac- 
cept, enter $8A. 

3. Press Inquiry 
Release key. 


30102 cu 


The retention period of the relevant 
output tape header label indicates 
that the tape should not be written 
on. (cu is the channel and unit of 
the relevant tape.) 


The IOCS can be 
directed to accept 
the tape, or to 
retry the label 
check with a dif- 
ferent tape 
mounted. 

1 . Press Inquiry 
Request key. 

2. To re-execute, 
enter $8R; to ac- 
cept, enter $8A. 

3. Press Inquiry 
Release key. 



Figure 122. iocs Tape Label Messages 

Appendix D: Work Files 

A work file is defined as a file that is used both as 
an input file and an output file. The capability to 
handle such a file is a feature of the iocs. Only one 



dtf statement is required to define a work file, be- 
cause the File Table generated by a dtf statement 
does not indicate whether the file is an input or an 
output file. However, the programmer must be careful 
to include all the dtf entries in the work file dtf state- 
ment that are appropriate to both an input and an 
output file of the relevant type (e.g., tape or disk). 

The iocs determines whether a work file is to be 
considered an input or an output file, when the file is 
opened by means of either the ioctl open,input or 
the ioctl open,output macro-instruction. For this 
reason, when the file is to be switched from an input 
file to an output file, or from an output to an input, 
the file must be closed by means of the appropriate 
ioctl close macro-instruction and then reopened. The 
ioctl open macro-instruction used to reopen the file 
indicates the file's new status. 



Appendix E: Modification of the File Table 
Extension 

The contents of the fields of the File Table Extension 
can be altered if the programmer wants: (a) an input 
header label to be checked against information other 
than that currently contained in the relevant File 
Table Extension (i.e., the information originally sup- 
plied by the dtf label entry and updated where ap- 
propriate by the iocs), or (b) an output header label 
to be written from information other than that cur- 
rently contained in the relevant File Table Extension. 
The following procedure can be used to alter the 
information contained in the fields of the File Table 
Extension: 

1. Before the affected file is opened, the user's pro- 
gram reads a card containing the desired information 
from the system's Standard Input Unit. (See the 
System Monitor publication. ) The format of this card 
is left to the user's discretion. 

2. The desired information is then moved from the 
siu input area (i.e., the area whose high-order position 
is labeled /crd/) into the relevant field or fields of 
the File Table Extension. 

3. The affected file is opened by means of an ioctl 
open macro-instruction. The label is then checked or 
written by the iocs, using the new information con- 
tained in the File Table Extension. 
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